传输层的数据结构是什么?
就是在问他的协议格式: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信号。