CS方式:客户-服务器方式
P2P方式:对等方式
其中客户和服务器指的是计算机的==进程==

带宽:网络中某个通道传送数据的能力.
(单位时间能网络中某个通道所能通过的最高数据率)

网络的利用率:有数据通过的时间百分比.

OSI的七层协议:
物理层–>数据链路层–>网络层–>运输层–>会话层–>表示层–>应用层
TCP/IP的四层协议:
网络接口层–>网际层IP–>运输层(TCP或UDP)–>应用层
五层协议:
物理层–>数据链路层–>网络层–>运输层–>应用层

HTTP协议

HTTP 的特性

  • HTTP 协议构建于 TCP/IP 协议之上，是一个应用层协议，默认端口号是 80
  • HTTP 是无连接无状态的

HTTP 报文:

HTTP 协议是以 ASCII 码传输
规范把 HTTP 请求分为三个部分：状态行、请求头、消息主体。

HTTP 中的GET，POST，PUT，DELETE就对应着对这个资源的查，增，改，删4个操作。

GET 请求不会修改，增加数据，不会影响资源的状态。
POST 表示可能修改变服务器上的资源的请求。

协议中没有规定数据使用哪种编码方式或者数据格式,
服务端通常是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码

HTTP 条件 GET 使用的方法？
客户端向服务器发送一个包询问是否在上一次访问网站的时间后是否更改了页面，如果服务器没有更新，显然不需要把整个网页传给客户端，客户端只要使用本地缓存即可，如果服务器对照客户端给出的时间已经更新了客户端请求的网页，则发送这个更新了的网页给用户。
==使用响应头的If-Modified-Since 字段判断响应文件没有更新==

HTTP 长连接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。
HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在 HTTP1.1 版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知

使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：

  1. 判断传输数据是否达到了Content-Length 指示的大小；
  2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，表明本次传输数据结束.

chunked 传输不能事先知道内容的长度，只能靠最后的空 chunk 块来判断，因此对于下载请求来说，是没有办法实现进度的。

默认情况下 HTTP 协议中每个传输层连接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。
HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程中不需等待服务端的回应。使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3。

管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变

什么是会话？
客户端打开与服务器的连接发出请求到服务器响应客户端请求的全过程称之为会话。

什么是会话跟踪？
会话跟踪指的是对同一个用户对服务器的连续的请求和接受响应的监视。

会话跟踪常用的方法:

  1. URL 重写

    URL重写的技术就是在URL结尾添加一个附加数据以标识该会话,把会话ID通过URL的信息传递过去，以便在服务器端进行识别不同的用户。

  2. 隐藏表单域

    将会话ID添加到HTML表单元素中提交到服务器，此表单元素并不在客户端显示

  3. Cookie

    Cookie 是Web 服务器发送给客户端的一小段信息，客户端请求时可以读取该信息发送到服务器端，进而进行用户的识别。对于客户端的每次请求，服务器都会将 Cookie 发送到客户端,在客户端可以进行保存,以便下次使用。

    客户端可以采用两种方式来保存这个 Cookie 对象，一种方式是保存在客户端内存中，称为临时 Cookie，浏览器关闭后这个 Cookie 对象将消失。另外一种方式是保存在客户机的磁盘上，称为永久 Cookie。以后客户端只要访问该网站，就会将这个 Cookie 再次发送到服务器上，前提是这个 Cookie 在有效期内，这样就实现了对客户的跟踪。

    Cookie 是可以被客户端禁用的。

  4. Session:

    每一个用户都有一个不同的 session，各个用户之间是不能共享的，是每个用户所独享的，在 session 中可以存放信息。

    在服务器端会创建一个 session 对象，产生一个 sessionID 来标识这个 session 对象，然后将这个 sessionID 放入到 Cookie 中发送到客户端，下一次访问时，sessionID 会发送到服务器，在服务器端进行识别不同的用户。

    Session 的实现依赖于 Cookie，如果 Cookie 被禁用，那么 session 也将失效。

HTTPS协议

流程:

  1. 首先,客服端请求服务器,将自己支持的加密算法，打个包告诉服务器端。
  2. 服务器从中选取一个加密算法和HASH算法(HASH算法是为了检验),然后加上自己的身份信息作为证书发回给客户端(证书中包含了网站的地址，加密用的公钥，以及证书的颁发机构).
  3. 客户端检验证书合法性.然后产生一个随机数,用发过来公钥加密.并且将同样的随机数使用发过来的HASH算法加密,生成一个校验值A,一并发给服务器.
    (简单来说就是使用公钥和HASH算法对同一个随机数加密,发给服务器)
  4. 服务器使用私钥解密,得到刚刚的随机数,然后使用同样的HASH算法对这个随机数加密,生成一个校验值B,比较校验值B,判断两者是否一样.一致则说明消息未被篡改，可以信任。
    最后，使用该随机序列号，加上之前第2步中选择的加密算法，加密一段握手消息，发还给客户端。同时HASH值也带上。
  5. 客户端收到服务器端的消息后，接着做这么几件事情：
     1）计算HASH值是否与发回的消息一致
     2）检查消息是否为握手消息
  6. 握手结束后，客户端和服务器端使用握手阶段产生的随机数以及挑选出来的算法进行对称加解密的传输。

简单的说:

  1. 客户端先告诉服务器自己支持的算法
  2. 服务器从中挑出一个算法,然后自己选一个hash算法,最后加上证书(证书有公钥),三个东西发给客户端
  3. 客户端现在收到三个东西:
    1. 先验证证书,
    2. 然后使用公钥加密一个随机数R,得到信息A
    3. 使用发过来的hash去映射这个随机数R,得到校验值A
    4. 最后将信息A,校验值A发给服务器
  4. 服务器现在收到两个东西:
    1. 将信息A使用私钥解密,得到随机数R
    2. 使用hash算法去映射这个随机数R,得到校验值B
      如果校验值A==校验值B,说明客户端确实是收到了服务器的公钥,并且这个随机数R确实是使用公钥加密的.
    3. 服务器以R为密钥使用了对称加密算法加密网页内容并传输给浏览器。
  5. 浏览器以R为密钥使用之前约定好的解密算法获取网页内容。

img

从上面的过程可以看到，TLS 的完整过程需要三个算法（协议），密钥交互算法，对称加密算法，和消息认证算法

TCP协议

在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP

TCP使用校验和，确认和重传机制来保证可靠传输
TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复

三次握手和四次挥手的最简单理解:
所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

建立TCP连接：三次握手协议

(第一次)客户端：我要对你讲话，你能听到吗；
(第二次)服务端：我能听到；而且我也要对你讲话，你能听到吗；
(第三次)客户端：我也能听到。
…….
互相开始通话
……..

二：关闭TCP连接：四次挥手协议

(第一次)客户端：我说完了，我要闭嘴了；
(第二次)服务端：我收到请求，我要闭耳朵了；
（客户端收到这个确认，于是安心地闭嘴了。）
…….
服务端还没倾诉完自己的故事，于是继续唠唠叨叨向客户端说了半天，直到说完为止
…….
(第三次)服务端：我说完了，我也要闭嘴了；
(第四次)客户端：我收到请求，我要闭耳朵了；（事实上，客户端为了保证这个确认包成功送达，等待了两个最大报文生命周期后，才闭上耳朵。）
（服务端收到这个确认，于是安心地闭嘴了。）

UDP协议

UDP 不保证数据报会到达其最终目的地，也不保证各个数据报的先后顺序，也不保证每个数据报只到达一次。
UDP 支持多播和广播。

IP协议

P 协议位于 TCP/IP 协议的第三层——网络层。与传输层协议相比，网络层的责任是提供点到点(hop by hop)的服务，而传输层（TCP/UDP）则提供端到端(end to end)的服务。