三次握手和四次挥手详细介绍(http的三次握手和四次挥手)

在传输层进行的。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。 （4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。
在TCP/IP（即DoD模型）的第三层，即“主机到主机”层。相当于OSI参考模型的传输层(第四层）。一般只说TCP的三次握手。当然，你要把拆除连接也算上，也可以叫四次握手。
TCP/IP由四个层次组成：网络接口层、网络层、传输层、应用层。 三次握手和四次挥手发生在第三层：传输层。 原因：三次握手四次挥手是tcp协议保证可靠全连接的手段，而tcp协议属于传输层协议，理所当然三次握手四次挥手是发生在第三层----传输层

#三次握手 客户端向服务器端发送SYN包，客户端进入SYN_SEND状态服务器端收到客户端发送的包返回ACK+SYN包，服务器端进入SYN_RECV状态客户端收到服务器端返回的包再发回ACK包，客户端进入ESTABLISHED状态，服务器端收到包也进入ESTABLISHED状态客户端状态：SYN_SENDESTABLISHED服务器端状态：SYN_RCVEESTABLISHED#四次挥手客户端发送FIN包询问服务器端是否能断开，客户端进入FIN_WAIT_1状态服务器端收到客户端发送的包并返回ACK包，服务器端进入CLOSE_WAIT状态服务器端准备好断开后，发送FIN包给客户端，服务器端进入LAST_ACK状态客户端收到服务器端发送的包后返回ACK包，客户端进入TIME_WAIT状态，服务器端收到包后进入CLOSED状态客户端状态：FIN_WAIT_1FIN_WAIT_2TIME_WAIT服务器端状态：CLOSE_WAITLAST_ACKCLOSED 如果有什么不懂的话可以去看看《Linux就该这么学》这本书，非常适合新手学习Linux。
三次握手： 第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。四次挥手与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

TCP是一种可靠的，面向连接的全双工传输层协议。TCP连接的建立是一个三次握手的过程。第一次：主机A（通常也称为客户端）发送一个标识了SYN的数据段，表示期望与服务器A建立连接，此数据段的序列号（seq）为a。第二次：服务器A回复标识了SYN+ACK的数据段，此数据段的序列号（seq）为b，确认序列号为主机A的序列号加1（a+1），以此作为对主机A的SYN报文的确认。第三次：主机A发送一个标识了ACK的数据段，此数据段的序列号（seq）为a+1，确认序列号为服务器A的序列号加1（b+1），以此作为对服务器A的SYN报文段的确认。 TCP连接的建立是一个三次握手的过程，而TCP连接的终止则要经过四次挥手。第一次：主机A想终止连接，于是发送一个标识了FIN，ACK的数据段，序列号为a，确认序列号为b。第二次：服务器A回应一个标识了ACK的数据段，序列号为b，确认序号为a+1，作为对主机A的FIN报文的确认。第三次：服务器A想终止连接，于是向主机A发送一个标识了FIN，ACK的数据段，序列号为b，确认序列号为a+1。第四次：主机A回应一个标识了ACK的数据段，序列号为a+1，确认序号为b+1，作为对服务器A的FIN报文的确认。以上四次交互便完成了两个方向连接的关闭。

1、建立连接协议（三次握手） （1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。　　2、连接终止协议（四次挥手）由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。　　CLOSED:这个没什么好说的了，表示初始状态。　　LISTEN:这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。　　SYN_RCVD:这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。　　SYN_SENT:这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。　　ESTABLISHED：这个容易理解了，表示连接已经建立了。　　FIN_WAIT_1:这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。　　FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。　　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: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。　　LAST_ACK:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。

我有一个朋友，小泷，他与我倾诉：他在咖啡厅与朋友闲谈，遇到了一个让时间彷佛静止的女孩。他描述，那一刻，他的心彻底被抓住了，脑中轰然，眼睛无法再从她身上移开。 而女孩，也时不时向她望来，那是一双如秋水般清澈的明眸。小泷说，他非常非常想想把握，这一次心动。然而，自始自终，他没能迈出那一步，他不知道该怎么办。小泷的困境，是每个男孩的困境。我告诉他，如果你懂得TCP协议，就会把握一段感情了。TCP(Transmission control protocal)，传输控制协议，既是机器与机器间传输信息的基础协议，也是人与人联立联系的准则。如何体面地认识她？ 如果读懂她是否对你有好感？ 如何给予她安全感？ 如何离别时要到她的手机号？ TCP协议，把一切写得清清楚楚。我对小泷说：一个女孩，不管她性格有多高冷，永远是欣然接受你的好感的。你要做的，也必须要做的，是：我告诉小泷，我也曾经在机场遇到过让我瞬间心动的女孩，我所做的，只是很自然走上去，告诉她："你好像也坐这趟飞机？ 航班号是KN5855没错吧"这对男孩是很简单的事情，因为你们出现的地点，就是共鸣。你关于这个地方，一定有一些具体信息可以分享。所以，小泷，你应走上去说：你也常来这家咖啡厅吧，他们家的焦糖玛奇朵非常棒。这样的谈话，对女孩是提供安全感的：你是一个拥有共同话题，并且会提供实质性价值的男士，而不是随随便便乱勾搭的人。 共鸣的力量是非常强大的，没有女孩会拒绝回应的，即使长相略显寒酸。说回TCP协议，它是这样规定的：(SYN是synchronization同步的简称，seq为sequcence序号的缩写。)这时，客户端的状态更改为SYN-SENT（synchronization_sent同步已发送）状态。也就是说，小泷，你耐心待着女孩回应就是了。这就是“第一次握手”。有了你提供的同步请求SYN=1和具体信息seq=x。女孩会根据这个信息做出响应。女孩这时的状态从LISTEN变为SYNC_RCVD（synchronization_recieved同步已收到）。我在机场遇到的女孩是这样回答我的：嗯嗯，我也坐这趟航班，不过没看到你。你是来深圳出差么？这样回答，是人之常情。你一定可以得到亲切友善的回应。TCP协议中是这样规定的：（ACK是acknowledgement确认的简称，小写的ack是确认编号)所以，女孩一定会认同你，并根据刚刚的信息点延展，而且会提供一个新的信息点。女孩对你不反感，但她也需要确认你是不是真对她有好感。假如我真的只是觉得航班数字很吉利呢？假如你小泷真是就喜欢喝焦糖玛奇朵呢？ 她无法确认男生是不是想和她交流，所以一定提出新话题。 而且，抛出新话题才会让彼此显得不尴尬。女孩几乎一定会这样回应：所以小泷，你心动女孩几乎一定会类似的回应：嗯嗯，我喜欢榛仁玛奇朵。我住这附近，你呢？你收到这样友好的回应，心中一定，知道，以后至少可以建立起初步的友谊了。 这时，你的状态更改为ESTABLISHED。(建立连接)虽然对于你，这段男女间青涩的友谊已经建立起了。但女孩，她还在等待你的回应 —— 她也在担忧你只是随意的询问吧。快赶紧安抚这一个善良美好的女孩吧！比如我会回答：嗯是的，有几个客户在深圳需要谈。我坐的商务舱所以没看到你吧。所以，小泷，你需要对她的新话题有所回应，并且不要丢掉自己的话题。这样两个话题都可以聊下去。在TCP协议中这样规定：这对女孩是非常重要的，你对她的话也表示认同，并且也能接住她的话题，同时自己的话题也没有丢掉。——是个能照顾她感受，也坚持自我的人。这时，女孩的状态成为了ESTABLISHED。你们双方都成为了ESTABLISHED，接下来，你们就可以畅通无阻地交流了。男孩会想，我怎么表现得靠谱？ TCP给出了答案，共鸣 + 具体话题。女孩心中会想： 他对我感兴趣吗？他是聊得来的人吗？ 如何进行“废物测试”？TCP给出了答案：共鸣 + 同意 + 对方话题的延展 + 新具体话题。男孩心中会想，怎么给她留下有主见高情商的好印象？TCP给出了答案： 同意 + 对方话题的延展 + 继续自己话题。仔细想想，这样的方式，让双方既不显尴尬，又体面舒适，又节约了两个人的时间与精力。时间总是短暂的，你们相谈甚欢，到了离别的时候。只有一个体面的离别，才意味着未来依然可以关系持续升温。放心，TCP协议已经为你规划好了。作为主动方的男生，需要首先表示分别，千万不要拖泥带水等到女生提出，这样才能为这段邂逅留下回味与不舍。你需要这时候，是要手机号/微信号的最佳时机。TCP协议是这样规定的：（FIN的意思是finis终结的意思）你已经请求结束了，安静地等待就好。 主动而沉默，给予女生足够的空间，这是最体面的分别方式。这时你的状态是FIN-WAIT-1（终止待待1）热情的聊天突然嘎然而止。女生心中会有些小失落，这时你要微信的请求，她几乎一定会同意。这时女生会找纸张，把自己的手机号或微信号写给你。并跟你说一些其它话。比如她说：嗯是的，等我写给你。你看外面好像快下雨了。TCP协议是这样规定的：因为是你提出离开，女孩还意犹未尽。一方面会同意离开，一方面会延展你的话题。为了确认你确实想离开了，她一般会说一个新话题，比如下雨了。女孩从接到你的离开请求，到回应你这一句的时候，她处于CLOSE_WAIT状态，她会开始进行心理建设，适应你离开时的空洞感。当然，成年人的表达方式，总是隐晦而体面的。只是一句淡淡的“天快下雨了”。而你听到她说这些，只是静静不说话。你进入FIN-WAIT-2状态。你在等着她的手机号，说话可能她突然不写了呢？忍住，别回应。当女孩低头写好手机号，她也做好了离开的心理建设，知道这一次邂逅到此为止了。这时，她说：快回去吧，我写给你啦。 不知道为什么和你呆一起挺愉快的。看，TCP协议影响着你们的一个个行为模式。你不回应，她会换个话题，她会开始猜，她会开始等，她会开始留恋。TCP协议是这样规定的：说出这句话的女孩，进入了LAST_ACK(最终动作)状态——主动权在你，她等着你。你听到女孩再次说话，你会不舍，你等着些什么。你进入TIME_WAIT阶段。知道她要离开了，你的心会突然一痛。但离开已成必然，体面地对她说最后的话吧！TCP协议是这样规定的：听到你说完这句话，女孩把车门关上，车缓缓启动了。女孩进入状态CLOSED（关闭连接）。提出离别的你，却久久站在原地。等了2MSL(两次交谈响应时间那么长)，你好希望车突然停下，女孩从车上下来。但一切没有发生。美好的邂逅结束了。你进入CLOSED状态。小泷，你知道吗？懂得TCP协议，也就懂得了如何去抓住属于撩拨你心弦的那个女孩。也许，这才是邂逅时应该的画面：离别时，你们会这样不舍离别：然后，她离开了。你凝望着她，一再回头，直到消失在视线外。每天，有万亿亿次TCP连接，都在为你重演着这一个画面。勇敢一点，不用担心被拒绝，万亿亿次TCP连接都成功了，你怎么会失败呢？因为TCP是网络通讯的规则，也是人类间默契的交流规则。不动声色，内心早已暗流汹涌。却只是对你说。“好巧，我也是这趟航班”几条规则，有助于你记住这一切：