计算机网络--应用层

1. 动态主机配置协议DHCP

注意，若不设置DHCP中继代理，路由器会直接丢弃广播发送的DHCP报文（路由器隔离广播域）

2.域名系统DNS

3.文件传送协议FTP

4.电子邮件

5. HTTP协议

5.1 请求报文

或称为请求行，请求头部，请求体

5.2 响应报文

或称为状态行，响应头，响应体

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

5.3 cookie与session

HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。cookie与session可以弥补HTTP协议无状态的不足。
　　如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

5.4 HTTP/HTTPS协议

1. HTTP/1.0

HTTP/1.0是一种 $无状态$ 的协议，服务器不跟踪也每个客户单，也不记录过去的请求。无状态性可以借助cookie/session机制来做身份认证和状态记录；采用$短连接$ 的方式通信，浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接。
HTTP/1.0的缺陷：

1. 由于采用短连接，无法复用连接，每次发送请求，都需要进行一次TCP连接，这使得网络的利用率变低。
2. 队头阻塞，由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

2. HTTP/1.1

HTTP/1.1相对于HTTP/1.0的改进：

1. HTTP/1.1支持$长连接$，HTTP1.1增加Connection字段，设置为Keep-Alive可以保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率，在请求头中携Connection:false来告知服务器关闭请求。
2. ⽀持$管道⽹络传输$，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。

HTTP/1.1的缺陷：

1. 虽然支持管道网络传输，解决了请求的队头阻塞，但并不是真正意义上的并行传输，仍然没有解决$响应的队头阻塞$问题，因为服务器仍然必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。
2. 没有请求$优先级控制$；
3. 请求 / 响应头部（Header）$未经压缩$就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
4. 发送$冗长的首部$。每次互相发送相同的⾸部造成的浪费较多；
5. $单向请求$，请求只能从客户端开始，服务器只能被动响应。

3. HTTP/2.0

HTTP/2.0相⽐ HTTP/1.1 性能上的改进：

1. HTTP/2.0支持$多路复⽤$，可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利⽤率。
2. HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据
   包做标记，指出它属于哪个回应。
   每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编号，其中规
   定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
   客户端还可以指定数据流的$优先级$。优先级⾼的请求，服务器就先响应该请求。
3. HTTP/2.0支持$头部压缩$，当发送的多个请求头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPack 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。
4. HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以$主动$向客户端发送消息。举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。
5. HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了$二进制格式$，计算机收到报⽂后，⽆需再将明⽂的报⽂转成⼆进制，⽽是直接解析⼆进制报⽂，这增加了数据传输的效率。
6. 基于HTTPS，$安全性$更加有保证。

HTTP/2.0的缺陷：多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。也就是说，HTTP2.0解决了请求的队头阻塞与响应的队头阻塞，但在$TCP层仍然有队头阻塞的问题$。

4.HTTP/3.0

HTTP/3.0相⽐ HTTP/2.0 性能上的改进：

1. HTTP/3.0 把 HTTP 下层的 TCP 协议改成了 UDP，可以解决由于TCP传输层导致的问题，UDP不管顺序，也不管丢包，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。 基于 UDP 的 QUIC协议 可以实现类似 TCP 的可靠性传输。QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发⽣丢包时，$只会阻塞这个流$，其他流不会受到 影响。
2. HTTPS 要建⽴⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。QUIC 直接 把以往的 TCP和 TLS/1.3 的 6 次交互合并成了 3 次，$减少了交互次数$。
3. 支持连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，实现了$连接迁移$的功能。
4. $TSL升级$成了最新的TLS 1.3 版本，
5. $头部压缩算法升级$成了 QPack 。

HTTP/3.的缺陷：
QUIC 是新协议，对于很多⽹络设备，根本不知道什么是 QUIC，只$被当做UDP不被识别$，这样会出现新的问题。所以HTTP/3.0 现在普及的进度⾮常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

5.5 HTTPS

在 https 的加密中，加密传输的数据本身使用的是对称加密，加密对称秘钥时使用的非对称加密。整个过程是这样的：server 端先生成一对非对称秘钥，将可以公开的公钥发送给 client 端，client 端也决定此次数据传输使用的对称加密算法和对称秘钥，然后利用 server 端给的公钥，对对称秘钥进行加密传输。server 端接受到 client 端发送的对称加密算法和秘钥后，server 端和 client 端的数据传输都使用这个对称秘钥和算法进行对称加密。整个过程中即便 server 端的公钥被中间人知道了内容，但是没有保存在 server 端的私钥，你是无法破译使用公钥加密的对称秘钥的。公钥原本就是可以被随意公开的，拿到也没用，解密需要的是私钥。非对称加密或者说公钥加密之所以能保证加密安全就是因为私钥是保密不公开的，攻击者没有私钥无法破译。
1.混合加密
在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
2.数字签名（相当于保证发送者的正确性）
可以通过哈希算法来保证消息的完整性；
可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）：通过「私钥加密，公钥解密」的方式，来确认消息的身份，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。
3.数字证书（为了保证发送者的正确性，必须保证公钥是没被伪造的）
CA(数字证书认证机构)用自己的死要把服务器的公钥加密后，办法数字证书，服务器将数字证书发送给客户端，客户端用CA的公钥解密出服务器端的公钥，如果能解密出来，证明数字证书是真实的。其中，CA的公钥事先已经内置到了浏览器或操作系统里。这样就可以确保服务器公钥的正确性。