北大青鸟java培训:网络编程的协议连接问题?
发布网友
发布时间：2022-12-17 00:47
共1个回答
热心网友
时间：2023-09-12 13:14
我们在前几期的文章中曾经给大家简单介绍了关于网络编程中不同协议的使用情况与运行的原理问题。
今天广西IT培训http://www.kmbdqn.cn/就继续来了解一下，关于网络编程中不同协议的状态连接问题。
1、为什么建立连接协议是三次握手,而关闭连接是四次挥手呢?这是因为服务端的LISTEN状态下的SOCKET收到SYN的请求连接时,可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里一起发送.但是关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送了,但是另一方未必所有的数据都全部发送完全了,所以可能不会立马关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方表示你同意现在关闭连接了,所以这里的2、ACK报文和FIN报文是分开发送的.为什么不能用两次握手进行连接?在三次握手中,总共需要完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已经准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认.现在把三次握手改成仅需要两次握手,是可能会发生死锁的.考虑计算机客户端和服务端之间的通信,假定客户端给服务端发送一个连接请求分组,服务端收到了这个分组,并发送了确认应答分组.按照两次握手的协定,服务端认为链接已经成功的建立了,可以开始发送数据分组.可是,客户端在服务端的应答分组在传输中被丢失的情况下,将不会知道服务端是否已准备好,不知道服务端建立什么样的序列号,客户端甚至会怀疑服务端是否收到自己的连接请求分组.在这种情况下,客户端认为连接还未建立成功,将忽略服务端发来的任何数据分组,只等待连接确认应答分组.而服务端在发出的数据分组超时后,重复发送同样的数据分组,就形成了死锁.3、为什么TIME_WAIT状态需要等2MSL后才能返回到CLOSED状态?什么是MSL?MSL即MaximumSegmentLifetime,也就是报文大生存时间.'MSL是任何报文段被丢弃前在网络内的长时间.'那么,2MSL也就是这个时间的两倍,当TCP连接完成四个报文段的交换时,主动关闭的一方将继续等待一定时间(2-4)分钟,即使两端的应用程序结束.4、为什么需要2MSL呢.一,虽然双方都同意关闭连接了,而且握手的四个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文.二,报文可能会被混淆,意思是说其他时候的连接可能会被当做本次的连接.当某个连接的一端处于TIME_WAIT状态时,该连接将不能再被使用.事实上,对于我们比较有现实意义的是,这个端口将不能再被使用.某个端口处于TIME_WAIT(其实应该是这个连接)状态时,这意味着这个TCP连接并没有断开(完全断开),那么.如果你bind这个端口,就会失败.对于服务器而言,如果服务器突然crash掉了,那么他将无法在2MSL内重新启动,因为bind会失败.解决这个问题的一个方法就是设置SOCKET的SO_REUSEADDR选项.这个选项意味着可以重用一个地址.当建立一个TCP连接时,服务端会继续用原有端口,同时用这个端口与客户端通信.而客户端默认情况下会使用一个随机端口与服务端的端口通信.有时候,为了服务端的安全性,我们需要对客户端进行验证,即限定某个IP的某个特定端口的客户端.客户端可以使用bind来使用特定的端口.对于服务端,当设置了SO_REUSEADDR选项时,它可以在2MSL内启动并listen成功.但是对于客户端,当使用bind并设置SO_REUSEADDR时,如果在2MSL内启动,虽然bind会成功,但是在windows平台上connect会失败.而在linux是哪个不存在这个问题.
