1 三次握手
TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须在双方之间建立一个连接。
在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号，并交换TCP窗口大小信息。
image.png
名词解释：
SYN：synchronous 同步。SYN是6个控制位中的一个，值为1时表示当前报文段的作用是同步序号。
seq：Sequence Number 序号。第一个字节的编号，在“TCP报文结构“中有介绍。
ACK：Acknowledgement 确认字符。ACK是6个控制位中的一个，值为1时表示前一个报文段已确认收到。
ack：小写的ack表示确认号。即接收方期望接收的下一个字节的编号。
第一次握手：
客户端发送SYN报文段，将SYN位置为1，seq为X(X为一个随机数)；然后客户端进入SYN_SEND状态，等待服务器的确认。
注意：这个报文段中不包括确认号，也没有定义窗口大小。SYN报文段是一个控制报文段，它不携带任何数据。但是它消耗了一个序号，当数据传送开始时，序号就应当加1。
第二次握手：
服务器发送SYN+ACK报文段，其中SYN和ACK这两个控制位都置为1。
这个报文段有两个目的：
-
服务器使用这个报文段来同步它的初始序号(seq)，以便从服务器向客户端发送字节。
-
服务器通过ACK标志告诉客户端已经收到来自客户端的SYN报文段。同时设置ack表示希望从客户端收到的下一个字节编号，也因为设置了ack，服务器还定义了接收窗口的大小(rwnd)。
此时服务器进入SYN_RECV状态。
注意：SYN+ACK报文段不携带任何数据，但要消耗一个序号。
第三次握手：
客户端发送ACK报文段。
ACK标志和确认号(ack)用于告诉服务器已经收到来自服务器的SYN+ACK报文段。
序号(seq)和第一次握手的SYN报文段的序号一样，也就是说这个ACK报文段不消耗任何序号。但在某些实现中，连接阶段的第三个报文段（ACK报文段）可以携带客户端的第一个数据块，此时，第三个报文段必须有一个新的序号来表示数据中的第一个字节编号。结论就是：ACK报文段如果不携带数据就不消耗序号。
此时客户端和服务器都进入了ESTABLISHED状态，完成TCP三次握手。（单词解释：establish:建立）
为什么要三次握手？
为了防止已经失效的连接请求报文段突然又传送到了服务器，因而产生错误。
具体例子：
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。
2 四次挥手
客户端和服务器通过三次握手建立了TCP连接，当数据传送完毕，需要断开连接，对于TCP的断开连接，有“四次挥手过程”。
image.png
第一次挥手：
主动方（可以是客户端或者服务器），设置seq=x，向被动方发送一个FIN报文段(FIN报文段可以包含要发送的最后一块数据)；此时，主动方进入FIN_WAIT_1状态；这表示主动方已经没有数据要发送给被动方了。
第二次挥手：
被动方收到了主动方的FIN报文段，向主动方回了一个ACK报文段，ack=x+1；此时主动方进入FIN_WAIT_2状态；这表示被动方告诉主动方，我“同意”你的关闭请求。
第三次挥手：
被动方向主动方发送FIN报文段，请求关闭连接；此时被动方进入LAST_ACK状态。
第四次挥手：
主动方收到被动方的FIN报文段，向被动方发送ACK报文段，然后主动方进入TIME_WAIT状态；被动方收到主动方的ACK报文段后，就关闭连接；此时主动方等待2MSL（MSL：Maximum Segment Lifetime，报文段最大生存时间）后依然没有收到回复，则证明被动方已正常关闭，那么主动方也可以关闭了。
为什么要四次挥手？
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
为什么要等待2MSL？
原因有二：
-
保证TCP协议的全双工连接能够可靠的关闭
-
保证这次连接的重复数据段从网络中消失
第一点：如果主机1直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN，此时由于主机1已经CLOSED了，就找不到与重发的FIN对应的连接。所以，主机1不是直接进入CLOSED，而是要保持TIME_WAIT状态。当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
第二点：如果主机1直接CLOSED，然后又再向主机2发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中（称为Lost Duplicate），这些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接要在TIME_WAIT状态等待2倍MSL，保证本次连接的所有数据都从网络中消失。
以上内容摘自：
https://github.com/LRH1993/android_interview/blob/master/computer-networks/tcpip.md
《TCP/IP协议族》第四版
网友评论