【计算机网络】TCP三次握手
本文为CSDN博主「小书go」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qzcsu/article/details/72861891
TCP的建立
最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。
SYN：同步标志位，用于建立会话连接，同步序列号。
ACK：确认标志位，当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。
seq：TCP通信过程中某一个传输方向上的字节流的每个字节的序号，通过这个来确认发送的数据有序，比如现在序列号为 1000，发送了 1000，下一个序列号就是 2000。
ack：TCP对上一次 seq序号做出的确认号，用来响应 TCP 报文段，给收到的 TCP 报文段的序号 seq 加 1。
Client→ Server: SYN=1，初始序列号 seq=x
Server→ Client: SYN=1，ACK=1，初始序列号 seq=y，ack=x+1（对于服务器来说，发送的数据从序列号y开始，接受的数据从序列号x+1开始）
Client→ Server: SYN=1，ACK=1，seq=x+1，ack=y+1（对于客户端来说，发送的数据从序列号x+1开始，接受的数据从序列号y+1开始）
为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
TCP连接释放
客户端主动关闭，服务端被动关闭
FIN：结束标志位，表示已经没有数据要发送了，即将关闭连接。
Client→ Server: FIN=1，序列号 seq=u
Server→ Client: ACK=1，序列号 seq=y，ack=u+1
Server→ Client: FIN=1，seq=w，ack=u+1
Client→ Server: SYN=1，ACK=1，seq=u+1，ack=w+1
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
————————————————
版权声明：本文为CSDN博主「小书go」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qzcsu/article/details/72861891