图文详解TCP/IP的“三次握手和四次挥手”工作原理

青旅半醒 2022-03-14 19:06 179阅读 0赞

首先，在讲之前，先说一下TCP和UDP，以及它们的区别：

**TCP**(Transmission Control Protocol 传输控制协议)：是一种面向连接的、可靠的、基于字节流的传输层通信协议，使用三次握手协议建立连接、四次挥手断开连接。面向连接意味着两个使用TCP的应用(通常是一个客户端和一个服务器)在彼此交换数据包之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信，广播和多播不能用TCP。

**UDP**(User Datagram Protocol 用户数据报协议)：是OSI参考模型中一种无连接的传输层协议，提供面向事务的简单但是不可靠信息传送服务。

**TCP和UDP的区别：**

传输层协议：

\---UDP(效率)

| -- 不建立连接。

| -- 数据不可靠。

| -- 把数据打包。

| -- 速度快。

| -- 数据有限制。64K。

| -- 64k = 64 \* 1024 byte = 64 \* 1024 /2 = 32768 汉字

\---TCP(安全)

| -- 建立连接通道。三次握手协议。

| -- 数据可靠。

| -- 数据没有限制。

| -- 速度慢。

一般的应用程序既有UDP协议还有TCP协议。

# **TCP/IP协议** #

**什么是协议？**

通信计算机双方必须共同遵从的一组约定。说白了就是-通信的规则。

**什么是TCP/IP协议？**

TCP/IP协议是一系列网络协议的总和；IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。TCP/IP 一词泛指这些协议，因此，有时也称 TCP/IP 为网际协议群。它定义了电子设备如何接入互联网，以及数据如何在它们之间互相传输。

**通俗理解TCP/IP协议：**

就好比中国人之间交流使用汉语，要遵循汉语的语法结构和发音；那如果我们跟英国人交流的话，就要使用英语的语法结构和发音；我们人与人之间交流所用的语言就是一种协议。对于计算机来说，两台机器之间的通信就要制定各种各样的协议，例如：文件传输使用TCP协议，域名系统使用DNS协议。数据根据协议规定的内容进行传输，这样就实现了两台机器之间的通信。

**TCP/IP分层：**

根据TCP/IP协议，我们可以把网络分成四层，分别为应用层，传输层，网络层以及链路层。而在OIS（Open System Interconnect）模型中，网络又可以分成七个层次，分别为应用层，表示层，会话层，传输层，网络层，数据链路层和物理层。为了研究方便，一般把网络分成五个层次，即应用层，传输层，网络层，数据链路层及物理层。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70][]

**TCP的有限状态机：11种状态**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 1][]

# **TCP/IP链接的建立过程：** #

TCP传输控制协议，是一个面向连接的协议。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手（ three-way-handshaking）进行初始化的。所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 2][]

首先，说一下图中涉及到的概念：

序列号Seq：用来标识数据包，发起方发送数据时对此进行标记。确认序号：ack序号，只有ACK标志位为1时，确认序号字段才有效，ack=Seq+1。

标志位：共6个，即SYN、ACK、PSH、RST、URG、FIN

SYN：发起一个请求。

ACK：确认序号有效

URG：紧急指针（urgent pointer）有效。

PSH：接收方应该尽快将这个报文交给应用层。

RST：重置连接。

FIN：释放一个连接。

需要注意的是：

不要将确认序号ack与标志位中的ACK不是同一个东西。

确认方Ack=发起方Seq+1，两端配对。

**图解TCP/IP连接建立过程：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 3][]

第一次握手中报文情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 4][]

第二次握手中报文情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 5][]

第三次握手中报文情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 6][]

第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN\_SENT状态，等待Server确认。

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN\_RCVD状态。

第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

**为什么不用两次握手创建连接？**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 7][]

可能发生死锁。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

**三次握手建立连接时，发送方再次发送确认的必要性：**

主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。

**四次握手：效率低**

“地瓜地瓜，我是土豆，收到请回答”

“地瓜收到！土豆土豆，我是地瓜，收到请回答”

“土豆收到！地瓜地瓜，我是土豆，收到请回答”

“...... ......”

“......嗯，这人怕是个傻子吧”

**总结：**

三次握手是在安全可靠的基础上，握手次数最少的方案。两次握手并不能保证可靠性。四次握手又浪费了效率，当然，有的需要更高安全性的地方，是可以有N次握手协议的，但那是特殊情况。

**SYN攻击：**

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN\_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

\#netstat -nap | grep SYN\_RECV

# **TCP/IP****链接的释放过程：** #

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 8][]

1.数据传输结束后，主机A的应用进程先向其TCP发出释放连接请求，不在发送数据。TCP通知对方要释放从A到B的连接，将发往主机B的TCP报文段首部的终止比特FIN置为1，序号u等于已传送数据的最后一个字节的序号加1。

2.主机B的TCP收到释放连接通知后发出确认，其序号为u+1，同时通知应用进程，这样A到B的连接就释放了，连接处于半关闭状态。主机B不在接受主机A发来的数据；但主机B还向A发送数据，主机A若正确接收数据仍需要发送确认。

3.在主机B向主机A的数据发送结束后，其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将终止比特置为1，并使其序号w等于前面已经传送过的数据的最后一个字节的序号加 1，还必须重复上次已发送过的ACK=u+1。

4.主机A对主机B的连接释放报文段发出确认，将ACK置为1，ACK=w+1, seq=u+1。这样才把从B到A的反方向连接释放掉，主机A的TCP再向其应用进程报告，整个连接已经全部释放。

**为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？**

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

**四次挥手释放连接时，等待2MSL的意义？**

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

1.为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。

2.防止已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

**TCP/IP协议通信的整体过程：**

通信的过程其实就对应着数据装包与拆包的过程。装包的过程，数据发送方每层不断地封装首部，添加一些信息用于传输，确保能传输到目的地。拆包的过程，数据接收方每层不断地拆除首部，得到最终传输的数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 9][]

1.数据在应用层经过了处理，比如把发送人，发送时间，发送内容等信息拼接成发送人：发送时间：发送内容发给对方；当然事实上不可能这么简单，想想http协议就知道了。

2.在应用层处理后的数据来到了传输层，这一层除了负责数据要发向对方哪个程序（端口），如果接的是TCP协议的话，还负责提供可靠传输。为了实现这些功能，需要加上TCP首部。

3.在传输层处理过的数据来到网络层，这一层负责数据要传向哪台主机，即加上对方主机的ip，所以我们要给来到网络层的包添加一个IP协议头。IP包生成以后，参考路由控制表决定接受此 IP 包的路由或主机。

4.IP包来到数据链路层被封装成以太网帧，以太网帧其实就是多了个对方mac地址。生成的以太网数据帧将通过物理层传输给接收端。

5.对方主机收到数据链路帧以后，对帧的接收mac地址进行解析，如果mac帧是传给自己的，则收下该帧并且传给上一层，否则把帧丢掉。

6.IP 模块接收到 数据后也做类似的处理。从包首部中判断此 IP 地址是否与自己的 IP 地址匹配，如果匹配则根据首部的协议类型将数据发送给对应的模块，如 TCP、UDP。这里的例子则是 TCP。对于有路由器的情况，接收端地址往往不是自己的地址，此时，需要借助路由控制表，在调查应该送往的主机或路由器之后再进行转发数据。

7.在 TCP 模块中，首先会计算一下校验和，判断数据是否被破坏。然后检查是否在按照序号接收数据。最后检查端口号，确定具体的应用程序。数据被完整地接收以后，会传给由端口号识别的应用程序。

8.应用层接到信息后进行解析，然后显示出来。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70]: /images/20220311/57a2e0864cd142d3a6a314f27d1d983f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 1]: /images/20220311/2382e3d96e1849049296a9e7411fb524.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 2]: /images/20220311/662aa79516f741d081b2aa8a3280002f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 3]: /images/20220311/74923f46704c4bb5a8fff0ee09ce448c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 4]: /images/20220311/39ec3ac3e9104662af1ca7b671556581.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 5]: /images/20220311/d37446dbc6de47b9a0104a3fdd339f59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 6]: /images/20220311/6cc9d4fec7bf4dea9d8dd44dcba37545.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 7]: /images/20220311/3dada0c17cf24aa19831fd7543afd5d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 8]: /images/20220311/ade20fea807f4e41a559ceb8f30d7152.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dueF81MjA1NQ_size_16_color_FFFFFF_t_70 9]: /images/20220311/21f5781f58b84a828f8f98ff376ea2a3.png