目录

一、面向连接

三次握手：

1、双方发送的数据包名称

 2.双方连接状态：

 问题：为什么tcp需要三次握手才能建立连接，两次不行吗？

3、包序管理(重要！！！)

序号与确认序号

通过抓包研究tcp的序号与确认序号

结论：纯ACK数据包不消耗序号

 发送数据的时候，针对每一个字节都进行了编号

二、四次挥手

2.1  连接数据包名称    双方连接状态

面试题1：挖坑分析TIME_WAIT的在哪里

面试题2：主动断开连接方为什么需要等待2MSL的时候之后，状态才能从TIME_WAIT状态，变迁为CLOSED状态

面试题3：如果服务端存在大量的TIME_WAIT状态，如何快速的重启进程？

一、面向连接

三次握手：

我们先来回想一下，三次握手是什么时候发生的呢？

结论1：服务端处于监听状态，客户端调用connect函数，才会进入三次握手阶段

结论2：三次握手阶段，程序猿没有具体参与，是由客户端和服务端的TCP协议进行连接的

1、双方发送的数据包名称

我们可以通过抓包来验证下三次握手的数据包名称：

 2.双方连接状态：

 问题：为什么tcp需要三次握手才能建立连接，两次不行吗？

1. 通过状态去解释

思路：2次握手，客户端认为连接已经建立，服务端认为连接还没有建立

2. 为什么服务端认为连接没有建立？

因为，没有第三次的ACK，服务端是没有办法确认，SYN+ACK数据包是否到达了客户端

3、包序管理(重要！！！)

先来复习一下TCP_socket的内容

服务端和客户端通过网络进行发送数据：

 结论:

tcp维护了发送缓冲区和接收缓冲区，send函数发送的内容， 会先放到tcp的发送缓冲区当中，tcp自己择机发送 (tcp自己选择发送的时机， 自己选择发送的数据量)。             rev函数接收的内容， 是从tp的接收缓冲区当中进行接收的， 接收的数量由
                                                              程序员调用的recv函数的第三次参数决定。

那么这个东西和包序管理有什么关系呢？

在上面的图中，不论是服务端给客户端发送数据还是客户端给服务端发送数据，都需要保证两个东西：

可靠：  一定要能 可靠到达对方

有序：  针对于应用层而言的，发送方发送的数据是有顺序的，接收方接收数据的时候也是有顺序的。

结论：TCP要保证可靠和有序，TCP的发送方在发送数据的时候，针对发送的数据，进行了序号的编号

序号与确认序号

那么服务端给客户端发送数据的时候有没有序号的编号呢？

肯定是有的，有两套序号

通过抓包研究tcp的序号与确认序号

序号：发送方发送数据的时候，针对数据的编号

确认序号：接收方告诉发送方，期望下一次发送方从哪个序号开始发送数据，引申含义就是：接收方告诉发送发，确认序号之前的内容都收到了

我们可以直接把之前的HTTP的数据包拿来分析，只分析里面的TCP的部分

 追踪一下就能得到：

 我们来分析一下这个过程：

 面试问题：

                双方在连接建立的过程，序号一定要从0开始吗？

不一定，只要满足后续发送的数据，按照之前的序号进行编号就行了

结论：纯ACK数据包不消耗序号

 我们现在用之前写的tcp_demo更好的理解一下这个：

 我们利用抓包分析一下这个过程

 上面过程画成图的话就是：

 发送数据的时候，针对每一个字节都进行了编号

 ack  = 发送方发送数据的起始序号  +   发送方发送的数据长度

二、四次挥手

2.1  连接数据包名称    双方连接状态

强调：在连接建立的情况下，双方都可以发起断开连接的动作

面试题1：挖坑分析TIME_WAIT的在哪里

客户端先告诉服务端连接断开，这个时候服务端存在大量的TIME_WAIT状态怎么办呢？

          1、 客户端由于是先给服务端发送的断开连接请求，所以TIME_WAIT状态不会存在服务端，而是客户端

           2、面试官你是想问客户端存在大量的TIME_WAIT状态吗？----》最终问题可能归结为服务端先断开，存在大量TIME_WAIT状态怎么解决？

面试题2：主动断开连接方为什么需要等待2MSL的时候之后，状态才能从TIME_WAIT状态，变迁为CLOSED状态

面试题3：如果服务端存在大量的TIME_WAIT状态，如何快速的重启进程？

 设置端口重用， setsockopt函数，就能解决这个问题。