传输层的数据结构是什么？
就是在问他的协议格式：UDP&TCP
2.1.1三次握手
通信前，要先建立连接，确保双方都是在线，具有数据收发的能力。
2.1.2四次挥手
通信结束后，会有一个断开连接的过程，避免出现意外。
FIN请求的功能： 只能表示不再给对方发送数据，不代表不接受数据
CLOSE_WAIT：等待关闭，对方发送了FIN包，已经不再给自己发送数据，上层如果这时候还在继续recv，则会读完缓冲区数据后，不再阻塞，而是返回0.这种情况下就是等待上层针对这种情况的处理。
为什么握手是三次？
握手三次：俩次不安全，四次没必要
1.通信前，要先建立连接，确保双方都是在线，具有数据收发的能力。因此都要SYN
2.俩次不安全：
有可能SYN会延迟到达，与重发的SYN形成冲突（三次有状态要求）
防止恶意攻击，比如客户端发送SYN后就直接退出
3.四次没必要：没必要发送俩次报文，在一次回复中将对应比特位置置1即可
2.1.3.2 挥手是四次？
FIN请求只能表示主动关闭方不再发送数据，不代表不再接收数据。因此，被动关闭方收到FIN包并进行确认后，还有可能会继续发送数据。等待上层不再发送数据了，也要关闭套接字了才会发送FIN包。
因此挥手没有合并为三次。
2.1.3.3 三次握手失败，俩端如何处理？
客户端发送第一次握手请求失败了，客户端会重传请求SYN。
第二次握手失败服务端回复的ACK + SYN丢失，客户端会重传，服务端在等待对方ACK回复超时后，给客户端发送一个RST报文，然后释放资源。
第三次握手失败，服务器超时，回复RST，然后释放资源。
2.1.3.4 一台主机出现了大量的CLOSE_WAIT状态连接，是什么原因？
只有收到FIN请求并进行了确认回复的连接会进入CLOSE_WAIT状态
一直处于CLOSE_WAIT而没有进入下一个状态，是因为上层没有进行关闭套接字操作，也就是没有发送FIN，所以没有进入下一步
因此原因就是代码中没有针对断开连接的套接字进行关闭处理
2.1.3.5 TIME_WAIT状态有什么用，为什么不直接关闭套接字释放资源？
TIME_WAIT状态是主动关闭方在发送最后一次ACK后进入的状态
如果没有TIME_WAIT，主动关闭方直接释放套接字资源，有可能出现新启动的套接字使用了与之前相同的地址信息
而上次通信可能最后一次ACK丢失，一旦丢失被动关闭方会重传FIN
就会导致上一次通信因为最后一次ACK丢失，而遗留问题（重传FIN）对新连接造成影响
因此不能直接释放资源，需要等待俩个MSL时间，针对有可能存在的FIN重传进行处理，并保证上一次通信的所有数据都消失在网络中。
MSL：报文最大生命周期，一个报文在网络中最大能存在的时间。默认60s
2.1.3.6 一台主机上出现了大量TIME_WAIT状态连接，是什么原因？怎么处理？
TIME_WAIT是状态是主动关闭方在发送最后一次ACK后进入的状态，等待一段时间是为了处理有可能因为FIN丢失导致的FIN重传的处理
因此一台主机出现大量的TIME_WAIT连接，是因为主机上大量的主动关闭了连接，常见于爬虫服务器
TIME_WAIT等待时间是可以配置的，可以将时间缩短
有个套接字选项，叫做地址重用：setsockopt();
tcp连接管理中的保活机制
连接断开有个信息：recv会返回0，send会触发异常SIGPIPE
tcp通信中，如果客户端和服务端的通信频率并不高，中间突然断网了，没有四次挥手的机会，如果俩端通信频率很低，可能需要很久才能发现。
在通信中，客户端与服务器若长时间无通信（默认7200s），则tcp服务器会自动向客户端发送保活探测心跳包，要求对方进行响应（默认每隔75s），若连续多次都没有收到响应（默认9次），则认为断开连接。
这些数据都可配置。甚至可以用套接字选项设置。
通常网络通信程序，在初始化阶段都会自定义SIGPIPE信号。