【网络编程】TCP三次握手及四次握手详解

清疚 2022-05-18 04:38 219阅读 0赞

## TCP通信时序 ##

\#\#\#一、概念  
\*\*TCP是一种面向连接的、可靠的协议，点到点的协议。\*\*有点像打电话，双方拿起电话互通身份之后就建立了连接，然后说话就行了，这边说的话那边保证听得到，并且是按说话的顺序听到的，说完话挂机断开连接。也就是说TCP传输的双方需要首先建立连接，之后由TCP协议保证数据收发的可靠性，丢失的数据包自动重发，上层应用程序收到的总是可靠的数据流，通讯之后关闭连接。  
\#\#\#二、TCP图解  
![70][]

TCP有源端口号和目的端口号，通讯的双方由**IP地址**和**端口号**标识。

16位源端口号，16位目的端口号，32位序号、32位确认序号，4位首部长度和IP协议头类似，表示TCP协议头的长度，以4字节为单位，因此TCP协议头最长可以是4x15=60字节，如果没有选项字段，TCP协议头最短20字节。URG、ACK、PSH、RST、SYN、FIN是六个控制位，16位检验和将TCP协议头和数据都计算在内。

\#\#\#三、实例说明  
下图是一次TCP通讯的时序图。TCP连接建立，断开，即三次握手和四次握手。  
**1、示意图**  
![70 1][]  
**2、详尽解析：**  
\*\*首先，\*\*客户端主动发起连接、发送请求，然后服务器端响应请求。\*\*然后，\*\*客户端主动关闭连接。

两条竖线表示通讯的两端，从上到下表示时间的先后顺序，注意，数据从一端传到网络的另一端也需要时间，所以图中的箭头都是斜的。双方发送的段按时间顺序编号为1-10，各段中的主要信息在箭头上标出，例如段2的箭头上标着SYN, 8000(0), ACK1001, ，表示该段中的SYN位置1，32位序号是8000，该段不携带有效载荷（数据字节数为0），ACK位置1，32位确认序号是1001，带有一个mss（Maximum Segment Size，最大报文长度）选项值为1024。  
\#\#\#\#\*\*【1】建立连接（三次握手）\*\*的过程：  
\*\*1.客户端发送一个带SYN标志的TCP报文到服务器。\*\*这是三次握手过程中的段1。  
客户端发出段1，SYN位表示连接请求。序号是1000，这个序号在网络通讯中用作临时的地址，每发一个数据字节，这个序号要加1，这样在接收端可以根据序号排出数据包的正确顺序，也可以发现丢包的情况，另外，规定SYN位和FIN位也要占一个序号，这次虽然没发数据，但是由于发了SYN位，因此下次再发送应该用序号1001。mss表示最大段尺寸，如果一个段太大，封装成帧后超过了链路层的最大帧长度，就必须在IP层分片，为了避免这种情况，客户端声明自己的最大段尺寸，建议服务器端发来的段不要超过这个长度。

**2.服务器端回应客户端，是三次握手中的第2个报文段，同时带ACK标志和SYN标志。**  
它表示对刚才客户端SYN的回应；同时又发送SYN给客户端，询问客户端是否准备好进行数据通讯。  
服务器发出段2，也带有SYN位，同时置ACK位表示确认，确认序号是1001，表示“我接收到序号1000及其以前所有的段，请你下次发送序号为1001的段”，也就是应答了客户端的连接请求，同时也给客户端发出一个连接请求，同时声明最大尺寸为1024。

\*\*3.客户必须再次回应服务器端一个ACK报文，\*\*这是报文段3。  
客户端发出段3，对服务器的连接请求进行应答，确认序号是8001。在这个过程中，客户端和服务器分别给对方发了连接请求，也应答了对方的连接请求，其中服务器的请求和应答在一个段中发出，因此一共有三个段用于建立连接，称为“三方握手（three-way-handshake）”。在建立连接的同时，双方协商了一些信息，例如双方发送序号的初始值、最大段尺寸等。

在TCP通讯中，如果一方收到另一方发来的段，读出其中的目的端口号，发现本机并没有任何进程使用这个端口，就会应答一个包含RST位的段给另一方。例如，服务器并没有任何进程使用8080端口，我们却用telnet客户端去连接它，服务器收到客户端发来的SYN段就会应答一个RST段，客户端的telnet程序收到RST段后报告错误Connection refused：  
$ telnet 192.168.0.200 8080  
Trying 192.168.0.200…  
telnet: Unable to connect to remote host: Connection refused  
\#\#\#\#【4】**数据传输的过程：**  
1.客户端发出段4，包含从序号1001开始的20个字节数据。  
2.服务器发出段5，确认序号为1021，对序号为1001-1020的数据表示确认收到，同时请求发送序号1021开始的数据，服务器在应答的同时也向客户端发送从序号8001开始的10个字节数据，这称为piggyback。  
3.客户端发出段6，对服务器发来的序号为8001-8010的数据表示确认收到，请求发送序号8011开始的数据。  
在数据传输过程中，ACK和确认序号是非常重要的，应用程序交给TCP协议发送的数据会暂存在TCP层的发送缓冲区中，发出数据包给对方之后，只有收到对方应答的ACK段才知道该数据包确实发到了对方，可以从发送缓冲区中释放掉了，如果因为网络故障丢失了数据包或者丢失了对方发回的ACK段，经过等待超时后TCP协议自动将发送缓冲区中的数据包重发。  
\#\#\#\#【4】关闭连接（四次握手）的过程：  
由于**TCP连接是全双工**的，因此**每个方向都必须单独进行关闭**。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。  
1.客户端发出段7，FIN位表示关闭连接的请求。  
2.服务器发出段8，应答客户端的关闭连接请求。  
3.服务器发出段9，其中也包含FIN位，向客户端发送关闭连接请求。  
4.客户端发出段10，应答服务器的关闭连接请求。

**建立连接的过程是三方握手，而关闭连接通常需要4个段，这就是我们常称的三次握手与四次挥手。**  
服务器的应答和关闭连接请求通常不合并在一个段中，因为有连接半关闭的情况，这种情况下客户端关闭连接之后就不能再发送数据给服务器了，但是服务器还可以发送数据给客户端，直到服务器也关闭连接为止。  
\#\#\#四、TCP状态转换

这个图N多人都知道，它排除和定位网络或系统故障时大有帮助，但是怎样牢牢地将这张图刻在脑中呢？那么你就一定要对这张图的每一个状态，及转换的过程有深刻的认识，不能只停留在一知半解之中。下面对这张图的11种状态详细解析一下，以便加强记忆！不过在这之前，先回顾一下TCP建立连接的三次握手过程，以及 关闭连接的四次握手过程。  
**【1】TCP状态转换图**  
![70 2][]  
**【2】示意图说明**  
**CLOSED：表示初始状态。**  
**LISTEN：该状态表示服务器端的某个SOCKET处于监听状态，可以接受连接。SYN\_SENT：这个状态与SYN \_ RCVD遥相呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，随即进入到了SYN \_ SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN\_SENT状态表示客户端已发送SYN报文。  
SYN\_RCVD: 该状态表示接收到SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂。此种状态时，当收到客户端的ACK报文后，会进入到ESTABLISHED状态。  
ESTABLISHED：表示连接已经建立**。  
**FIN\_WAIT\_1**: FIN \_ WAIT \_ 1和FIN \_ WAIT\_2状态的真正含义都是表示等待对方的FIN报文。  
**区别**：  
**FIN\_WAIT\_1**状态是当socket在ESTABLISHED状态时，想主动关闭连接，向对方发送了FIN报文，此时该socket进入到FIN\_WAIT\_1状态。  
**FIN\_WAIT\_2**状态是当对方回应ACK后，该socket进入到FIN\_WAIT\_2状态，正常情况下，对方应马上回应ACK报文，所以FIN\_WAIT\_1状态一般较难见到，而FIN\_WAIT\_2状态可用netstat看到。  
\*\*FIN\_WAIT\_2：主动关闭链接的一方，发出FIN收到ACK以后进入该状态。称之为半关闭状态。\*\*该状态下的socket只能接收数据，不能发。  
TIME\_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，等2MSL后即可回到CLOSED可用状态。如果FIN\_WAIT\_1状态下，收到对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME\_WAIT状态，而无须经过FIN\_WAIT\_2状态。  
**CLOSING**: 这种状态较特殊，属于一种较罕见的状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。  
**CLOSE\_WAIT**: 此种状态表示在等待关闭。当对方关闭一个SOCKET后发送FIN报文给自己，系统会回应一个ACK报文给对方，此时则进入到CLOSE\_WAIT状态。接下来呢，察看是否还有数据发送给对方，如果没有可以 close这个SOCKET，发送FIN报文给对方，即关闭连接。所以在CLOSE\_WAIT状态下，需要关闭连接。  
**LAST\_ACK**: 该状态是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，即可以进入到CLOSED可用状态。  
**TAIM\_WAIT**：**等待状态,2MSL，大约一分钟左右。**  
\#\#\#\#五、思考题：  
**为什么A在TIME-WAIT状态必须等待2MSL时间？**  
（1）、A发送的最后一个ACK报问能够到达B。该报文可能丢失。若丢失，在CLOSE\_WAIT状态的B会重传FIN+ACK报文，而A在2MSL的时间会收到B重传的报文，接着A重新发出确认，重新启动2MSL定时器，最后A和B都进入到CLOSED状态，如果A不设置计数器等待，则A在发送完ACK后立即释放连接，若ACK丢失，则A就发送收到重传，B无法进入CLOSED状态。  
（2）、防止已失效的连接请求报文（在网络上因时延耽搁的链接请求）出现在本连接中。A在发送完确认报文ACK后，经过2MSL的时间，就可以使本链接持续的时间内产生的所报文段都从网络上消失，下一个新连接中不会出现旧的连接请求报文段。

[70]: /images/20220518/62db276988dd4c2aa98b329a18aaf414.png
[70 1]: /images/20220518/ca097f5b5c2042c9822a7cfd8edefc36.png
[70 2]: /images/20220518/4df53af284f847498746bd3e093842a0.png