TCP的三次握手和四次挥手

转载https://blog.csdn.net/qzcsu/article/details/72861891

简述tcp
tcp把连接作为基本对象，每一个tcp的连接都有两个端点，这两个端点叫做套接字。tcp的定义是端口号拼接IP地址构成套接字。栗子:192.168.2.123:80(端口号为80,192.168.2.123为IP地址)

tcp建立连接(这就是传说中的三次握手)

上图，来看看是咋握的手

我理解的三次握手就类似那对讲机和同一频道的人说话:
第一次握手:客户端请求服务，携带报文段，和客户端的初始序列号。类比生活中-->我要告诉对讲机的人，我叫什么，编号是啥
第二次握手:服务器响应客户端，携带报文段，服务器端的初始序列号，确认号。类比生活中-->对讲机的人告诉我，他叫什么，他的编号是啥，顺带着他会告诉你他知道了你的名字，咱俩的暗号是啥
第三次握手:客户端会再次请求一次服务器，携带报文段，客户端序列号，确认号。类比生活中--->因为自己平时做事很细心。我怕对讲机不好用，我又确认了一下，是不是自己的对讲机是可以用的。这时候，我会告诉对方我知道了你叫什么，我的编号是啥，暗号是啥。

有的人会疑惑其实两次握手就可以，为什么要三次握手？
我看到大牛如下所述进行解释的，我觉得讲的很不错，拿来用。(此牛--->https://blog.csdn.net/qzcsu/article/details/72861891)

'''

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

'''

类比生活中--->我就想找个有对讲机能听我说话的人，如果我第一次说了自己叫什么，对讲机没人鸟我，我会认为是不是这个频道没人，这时候我又拿着对讲机喊了两嗓子，有人搭理我了完成两次握手。但是，实际上第一次喊对方时不是没人，而是网络问题，信号不稳，当网络恢复正常后，收到消息，这时候，对方在回应我完成两次握手，我是不需要的。因为我在第二次喊人的时候就有人回应并解决了我的问题当然就不需要重复听一个问题的答案了。

tcp断开连接(四次挥手)

上图，来看看是如何挥手

举栗子来更加理解四次挥手：

第一次挥手:客户端向服务器发送结束连接的请求 ，携带报文段，和自己序列号 。抽象理解-->A 告诉 B停止传输数据吧

第二次挥手:服务器响应客户端，携带着确认的报文，和自己的序列号。抽象理解-->B回应A，我知道了。此时，B还要告诉为A提供服务的C(应用进程)不用提供服务了。注意啦，此时可以肯定A已经没有要发送的数据了，但是不能确定B，因此这时候B还是可以向A发送数据的(这里数据指的是剩余没发送完的数据)
第三次挥手:当服务器将全部的数据传输完成后，再次响应客户端，携带连接释放报文(确认报文)【（如果你问，第二次挥手的时候就带着确认报文呢，怎么第三次还要发确认报文，我理解的是，第二次挥手的确认报文是告诉我客户端，我知道了，第三次挥手的报文是告诉客户端，这次数据都传完了）】，自己的序列号。 抽象理解-->B把该给A的数据都传完后，得告诉A一声，让A知道B这边的都搞定了
第四次挥手:客户端请求服务器，携带确认报文和自己的序列号。抽象理解--->A收到B的消息，知道了，B已经确认没有数据要传输了，自己这边得告诉B，自己知道了，确认已经接到你发的消息了。
这就是四次挥手，如果你问我，图中客户端还有一个等待时间，怎么没有提及到。
解释这个还是让大牛来解释一下吧 （大牛-->https://blog.csdn.net/qzcsu/article/details/72861891）

'''

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

'''

自己理解的是，若客户端出现丢包的情况，这样能够让服务器自身意识到自己发的包是不是没有被对方收到，因此等待时间就可以让服务器再次向客户端发送确认断开请求