1.TCP的许多特性都与TCP是面向连接的这个特性有关。每一条TCP连接有两个端点,那么TCP连接的端点是什么呢?不是主机,不是主机IP,不是进程,也不是运输层的协议端口,TCP连接的端点叫套接字,端口号拼接到IP地址即构成了套接字。
2.传输连接有三个阶段,包括连接建立数据传送和连接释放。
在TCP连接建立过程中要解决以下问题:
(1)要使每一方都能确认对方的存在
(2)要允许双方协商一些参数(如最大窗口值,是否使用最大窗口扩大选项和时间戳选项以及服务质量等)
(3)能够对运输实体资源(如缓存大小,连接表中的项目)进行分配
主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫做服务器。
3.TCP连接的建立过程(三次握手)
假定主机A运行的是TCP客户程序,而B运行TCP服务器程序,最初两端的TCP进程都处于CLOSED(关闭状态),A主动打开连接,B被动打开连接
客户端状态的转化:
[SYN-SENT->ESTABLISH]:connect()调用成功 ,则进入ESTABLISH状态,开始读写数据
服务器状态转化:
[SYN-RCVD->ESTABLISH]:服务端一旦收到客户端的确认报文,就进入ESTABLIASH ,就可以进行数据的读写了
在建立连接的过程中,客服务器的进程分别先建立传输控制块TCB,准备接受客户进程的连接请求,然后服务器进程就进入listen状态,等待客户端的连接请求。
TCP的客户也建立一个TCB,向B发出连接报文段,这时首部中的同步为SYN=1(在建立连接时用来同步序号),同时选择一个初始序号seq=x,TCP 规定:SYN报文段不能携带数据,但要消耗一个序号,这时客户端进程进入SYN-SENT(同步已发送)状态
服务器收到连接请求报文后,如果同意建立连接,则向客户发送确认,在确认报文中应把SYN位和ACK位都置为1,确认号是ack=x+1,同时也为自己选择一个初始序号seq=y,这个报文段也不能携带数据,但同样也要消耗掉一个序号,这时服务器进程进入SYN-RCVD(同步收到)状态。
TCP客户收到服务器的确认后,还要向服务器给出确认,确认报文段的ACK置1,确认号ack=y+1,而自己的序号seq=x+1,TCP标准规定,ACK报文段可以携带数据,但如果不携带数据就不消耗序号。这时,TCP已经建立连接,客户进入ESTABLISH(已经建立连接)状态
当服务器收到客户端的确认后,也进入ESTABLISH状态。
4.为什么要进行三次握手
主要是为了防止已失效的报文段突然又传送到服务器,因而产生错误。
正常情况下,客户发出连接请求,但因连接请求报文丢失而为收到确认,于是客户再重传一次连接请求,后来收到确认,建立连接,数据传输完后释放连接,客户一共发送了两个连接请求报文段,其中第一个丢失,第二个传送到服务器端,没有已失效的连接请求报文段
异常情况,客户发出一个连接请求报文段,并且没有丢失,而是在某些网络节点长时间滞留了,以致延误到连接释放以后的某个时间才到达服务器端,本来者是一个早已失效的报文段,但服务器收到这个已经失效的报文段之后,就误认为是客户端又发送了一次新的连接请求,于是向客户端发出确认报文段,同意建立连接。假定不采用三次握手,这是就确认新的连接建立了。由于客户没有发出建立连接的请求,因此不会理睬服务器端的确认,但服务器端却认为新的连接已经建立了,并一致等待客户端发来数据,服务器的许多资源被白白浪费了;如果采用三次握手,客户端不会向服务器端的确认发出确认,服务器端由于收不到确认,就知道客户端并没有要求连接建立。
4.TCP的连接释放过程
数据传输结束后,通信的双方都可释放连接,现在客户端(A)和服务器端(B)都处于ESTABLISH状态,A的应用程序先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接,A把释放报文段首部的终止控制位FIN置为1,其序号seq=u,它等于前面已经传送过的数据的最后一个字节的序号加1,这时A进入FIN-WAIT-1(终止等待1)状态,等待B的确认,TCP规定:FIN报文段即使不携带数据,它也消耗掉一个序号。
B收到A发来的释放报文段后即发出确认,确认号是ack=u+1,假设这个报文段自己的序号是v,等于B前面已经传送过的数据的最后一个字节的序号加1,然后B就进入CLOSE-WAIT(关闭等待)状态,TCP服务器进程这时应通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP处于半关闭状态,即A已经没有数据要发送了,但是若B要发送数据,A仍要接收,B到A这个方向的连接并没有关闭,这个状态可能会持续一段时间。
A收到B的确认后,就进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。
如果B已经不需要向A发送数据了,其应用进程就通知TCP释放连接,这是B发出的连接释放报文段将FIN置为1,现假定B的序号为w(在半关闭状态下,B可能又发送了一些数据),B还必须重复上次已经发送过的确认信号,
ack=u+1,这时B就进入LAST-ACK(最后确认)阶段等待A的确认
A在收到B的连接释放报文段后,必须对此发出确认,在确认报文中把ACK置1,确认序号ack=w+1,而自己的序号seq=u+1,然后就进入TIME-WAIT(时间等待状态),这时TCP连接并没有是放掉。必须经过时间等待计时器设置的时间2MSL后,A才进入到CLOSED状态。当A撤销相应的传输控制块TCB后,就结束了这次TCP连接。
5.为什么A在TIME-WAAIT状态下必须等待2MSL的时间呢?
(1)为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失,因而使处于LAST-ACK状态的B收不到对方发送的FIN-ACK报文段的确认,B会超时重传FIN+ACK报文段,而A就能在2MSL时间内收到这个重传的FIN+ACK 报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入CLOSED状态。如果A在TIME状态下不等待一段时间,而是在发送完ACK报文段后立即释放连接,就无法收到B重传的FIN+ACK ,因而也不会再发送一次确认报文段,这样B就无法按步骤进入CLOSED状态。
(2)A发送完最后一个ACK报文段后,在经过2MSL后,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,这样就不会使下一个新的连接中出现旧的连接请求报文段。B只要收到A发出的确认,就进入CLOSED状态。同样,B在撤销相应的传销控制块TCB后,就结束了这次TCP连接,B结束TCP连接的时间要比A早一些。
除了时间等待计时器外,TCP还有一个保活定时器,当客户与服务器主动建立连接后,客户端主机突然出现故障,显然服务器端就收不到客户端发来的数据,这就需要保活定时器,服务器每收到一次客户端的数据,就重新设置保活计时器,时间设置通常是两小时。
TCP协议规定,最先发起断开连接的一方需要等待2msl,2msl是指一个报文生存的最大时间,msl的值Centos7上默认是60s,可以通过
cat /proc/sys/net/ipv4/tcp_fin_timeout
查看msl的值。
解决在TAIME_WAIT状态下引起bind失败的方法?
在服务器的TCP连接没有完全断开之前,不允许重新监听,但这在某些情况下是不要合理的。当服务器要处理大量的客户端的连接,这时候由服务器主动关闭连接,就会产生大量的TIME_WAIT连接。由于我们的请求量很大,就可能导致TIME_WAIT的连接数很多,导致服务器的端口不够用,无法处理新的连接。这时,我们可以使用setsockopt()函数设置socket描述符的选项SO_REUSEADDR为1,表示允许创建端口号相同但IP地址不同的多个socket描述符。