vlambda博客
学习文章列表

作者：登楼应登楼
链接：https://juejin.cn/post/6936807481301532702
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一、5层协议体系结构

1.各层作用

• 应用层

任务：通过应用进程间的交互来完成特定网络应用。

数据单元：报文。

协议：http、ftp、域名系统DNS协议等。

• 传输层

任务：负责向两台主机进程之间的通信提供通用的数据传输服务。

数据单元：报文段

协议：TCP，UDP协议。

• 网络层

任务：在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。

数据单元：IP数据报（数据报）。

协议：IP协议。

• 数据链路层

数据单元：帧。

• 物理层

任务：实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。

数据单元：比特。

2.数据封装与解封装

说明：

① 在主机上的数据DATA，应用层加上一些控制信息，DATA+控制信息形成报文。

②报文分成段之后存放到传输层中，加上传输层的控制协议形成报文段。

③报文段与网络层的控制信息一起形成数据报。（数据报过长时可以进行切分形成分组）

④数据报在头尾部分加上数据链路层的控制信息形成帧。

⑤帧在物理层中被转化为比特流的形式进行传输。

解封装是封装的逆过程。

二、TCP、UDP协议

1. TCP

1.1 主要特点

• 面向连接  。

• 虚连接，不是完整的物理连接。

• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。

• 不能使用广播或多播方式。

• 可靠有序，不丢不重。

• TCP提供可靠交付的服务，无差错，不丢失，不重复，按序到达。

• 提供全双工的通信。

• 发送缓存    准备发送的数据和已发送但尚未收到确认的数据

• 接收缓存    按序到达但尚未被接收应用读取的数据和不按序到达的数据

• 面向字节流。

• 把应用程序交下来的数据看成仅仅是一连串的无结构的字节流

1.2 TCP连接管理

1.2.1 TCP连接的三次握手

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。

说明：

• 同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

• 确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；

Q 1：为什么要三次握手？

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、自己接收正常，对方发送、对方接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、自己接收正常，对方发送、对方接收正常；Server 确认了：自己发送、自己接收正常，对方发送、对方接收正常

Q 2：第2次握手传回了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。”

Q 3：不能二次握手吗，第三次握手的重要性？

假设TCP连接不需要第三次握手，即只要Server发出确认报文后，TCP就建立连接（两次握手），那么会出现什么问题？

Server端会因接收了早已失效的报文，从而一直等待客户端的请求，最终导致死锁，资源浪费。

什么是早已失效的连接请求报文段？

当客户端发出的第一个连接请求报文段无丢失，而是在某个网络节点长时间滞留了，导致延误到连接释放后的某个时间才到服务器，这种连接请求报文段是无效的。

当TCP连接只需要两次握手时，服务器端接收到了无效的连接请求报文段，就会误认为是客户端发出的一个新的连接请求，于是像客户端发出了确认报文段，同意建立TCP请求。因为假设了只需要两次握手，那么此时TCP连接就已经建立了。但是对客户端来说，它并没有发出建立连接的请求，所以不会向服务器端发送数据。但对服务器端了来说，因为它误以为客户端发出了建立连接的请求，所以它会一直等待客户端发送数据，最终导致死锁状态。

为了解决这个问题，就需要采用第三次握手，当服务器端发出了确认请求报文段之后，客户端并不会向服务器端的确认报文段发出确认，服务器收不到客户端发来的确认信息，就知道客户端并没有发出建立连接的请求，就不会一直等待客户端发送数据。所以三次握手就能确认双发收发功能都正常，缺一不可。

SYN洪泛攻击：

• 从上可看出：服务端的TCP资源分配时刻 = 完成第二次握手时；而客户端的TCP资源分配时刻 = 完成第三次握手时

• 这就使得服务器易于受到SYN洪泛攻击，即同时多个客户端发起连接请求，从而需进行多个请求的TCP连接资源分配

1.2.2 TCP释放连接的四次挥手

断开一个 TCP 连接则需要“四次挥手”：

• 客户端-发送一个 FIN,设置为1，用来关闭客户端到服务器的数据传送

• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号

• 服务器-关闭与客户端的连接，发送一个FIN给客户端

• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

Q 1：为什么TCP释放连接需要四次挥手？

TCP连接提供全双工通信，即客户端收发信息，服务器端也可以收发信息。

TCP释放连接的目的是达到双方都无法接收信息。假设此时采用两次挥手，即客户端像服务器端发送了释放连接请求，并且服务器端返回确认释放连接信息时，此时，TCP连接是处于半关闭状态，即客户端无法发送信息给服务器端，但仍然可以接收来自服务器端的信息（服务器端可以发信息给客户端），因此需要再进行二次握手，即服务器端向客户端发送释放连接的请求，并且客户端向服务器端发送确认释放连接的请求，才真正完成释放（双向）。

补充：客户端再关闭连接前需要等待2MSL（MSL是最长报文段寿命）时间。

Q 2：为什么需要等待2MSL时间？

① 客户端发送的最后一个连接释放请求报文可能丢失，当服务器端接收不到连接释放确认报文时，不会进入关闭状态，但会超时重发连接释放报文。等待2MSL时间就是为了保证客户端发送的最后一个连接确认报文能够到达服务器。假设客户端没有等待2MSL时间就直接关闭连接，当客户端最后一个确认报文丢失时，服务器超时重发释放连接请求，因为此时客户端连接已经关闭，因此接收不到服务器发送的信息，服务器一直接收不到客户端发送的确认信息，导致无法进入关闭状态。

解决这个方法就是让客户端关闭连接前等待2MSL时间，客户端发送最后一个确认报文段后，启动2MSL计时器。若最后一个报文段丢失，服务器超时重发，客户端也能再次接收到服务器的信息，并且重新发送释放连接确认报文段。

② 客户端发送了最后1个连接释放请求确认报文后，再经过2MSL时间，则可使本连接持续时间内所产生的所有报文段都从网络中消失。防止早已失效的连接请求报文 出现在本连接中。

1.3 TCP可靠传输

网络层是不可靠传输，需要靠上一层即传输层实现可靠传输（TCP），若传输层使用的是UDP协议，则需要靠上一层（应用层）实现网络传输。

Q：TCP 协议如何保证可靠传输？

1. 应用数据被分割成 TCP 认为最适合发送的数据块。

2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

4. TCP 的接收端会丢弃重复的数据。

5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口(ARQ协议)实现流量控制）

6. 拥塞控制： 当网络拥塞时，减少数据的发送。

   拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。

Q：拥塞控制和流量控制的区别？

拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制的四种算法：

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。

• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.

补充：cwnd=拥塞窗口，ssthresh = 慢开始门限。

7. 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

自动重传ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

• 停止等待ARQ协议

原理：

1. 点对点发送数据报，等待接收端回复并开始计时

2. 等待开始时，发送端停止发送新数据包

3. 当数据包没有成功被接收端接收时，接收端不发送ACK包，发送端将继续等待一段时间并重新发送数据包

4. 重复以上步骤，直到接收到接收端发来的ACK

优点：

原理简单，广泛运用于分组交换网络。

缺点：

较长的等待时间，使得数据传输速度低。低速传输时频道利用率较高，高速传输时频道利用率较低。

• 回退N帧ARQ协议

原理：

1. 接收端丢弃从第一个没有收到的数据包开始的所有数据包

2. 发送端收到NACK后，从NACK中指明的数据包开始重新发送

优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。

• 选择性重传ARQ协议（Selective Repeat）

原理：

1. 发送端连续发送数据包但对每个数据包都设有个一个计时器

2. 当在一定时间内没有收到某个数据包的ACK时，发送端只重新发送那个没有ACK的数据包







8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

2. UDP

主要特点：

• 无连接，减少开销和发送数据之前的时延

• 不保证可靠交付（由应用层保证）

• 面向报文，适合一次性传输少量数据的网络应用

• UDP无拥塞控制，适合很多实时应用（视频会话等）

• UDP首部开销小，8B，TCP 20B

Q:什么是面向报文的?

应用层给UDP多长的报文，UDP就照样发送，即一次发一个完整报文。（因此使用UDP协议时需要考虑报文大小，适合传输少量数据的网络应用，报文也不能太小，会降低网络层的效率，大小要适当）

三、HTTP

http介绍：

http是一种超文本传输协议，作用在应用层上，它规定了应用进程间通信的准则。

特点：

• 无状态（不保存状态，即无法记录用户的操作）

• 传输可靠性高

HTTP协议定义了浏览器（万维网用户进程）怎样向万维网服务器请求万维网文档，以及服务器怎么样把文档传送给浏览器

3.1 HTTP的连接方式

1.非持久连接

在HTTP/1.0中默认使用非持久连接，客户端和服务器每进行一次HTTP操作，就建立一次连接（三次握手），任务结束就中断连接。

2. 持久连接

HTTP 1.1起，默认使用持久连接 ,默认开启Connection：keep-alive。

• 非流水线式

非流水线式：客户在收到前一个响应后才能发送下一个请求。

• 流水线式

流水线式：客户在收到HTTP的响应报文之前就能接着发送新的请求报文

HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

HTTP 和 HTTPS 的区别？

1. 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

2. 安全性和资源消耗：

   HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

• 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

• 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

---

参考：

• 2019 王道考研 计算机网络

• JavaGuide

• 计算机网络：这是一份非常全面&详细的TCP/IP协议学习指南

• 计算机网络基础：这是一份详细 HTTP 学习指南