一、连接管理

建立连接,断开连接

建立连接,TCP有连接的.

客户端执行  socket = new Socket(SeverIP,severPort);   ->   这个操作就是在建立连接.

上述只是调用socket api,真正建立连接的过程,实在操作系统内核完成的.

内核是怎样完成上述的 " 建立连接 "过程的呢?

称为 " 三次握手 ",此处谈到的连接, "虚拟的,抽象的,"连接,目的是让通信双方都能保存对方的信息.

客户端是主动的一方,第一次交互一定是由客户端发起的.

所谓syn是一个特殊的TCP数据报,

1. 没有载荷,不会携带应用层数据

2. 六个标志位中的第五位,为1.

表示想和对方建立连接.

虽然syn不带有应用层载荷,但是也会带有IP报头,以太网数据帧...更会有TCP报头.

TCP报头中,就包含了客户端自己的端口.IP报头中就包含了客户端自己的IP

上述流程中有四次交互,但实际过程中,有两次交互可以合二为一,最终就形成了 " 三次握手 "

所谓的建立连接过程,本质上就是通信双方各自给对方发送一个syn,各自给对方回应一个ack.

虽然第一次握手,客户端已经把自己的信息告诉服务器了.但是服务器具体是否要确定存储这个信息,还得再观望,等到所有的握手环节结束,服务器才会最终保存客户端的相关信息.

上述过程中,有两次可以合二为一.

syn就是第五位为1,ack就是第二位为1.

完全可以有一个数据包,第二位和第五位都是1,这个数据包就能同时起到两个作用.

网络传输过程中,要涉及到多次的封装 和 分用

两个包就封装分用两次,合并成一个包,就可以减少一次封装分用的过程,整体效率就提高了,成本就降低了.

二、三次握手的意义

1. 三次握手,可以针对通信路径,进行投石问路,初步的确认一下通信链路是否通畅,

2. 三次握手,也是在验证通信双方,发送能力和接收能力是否正常.

3. 三次握手的过程中也会协商一些必要的参数,通信是客户端服务器两方的事情,要配合,其中的有些内容要保持一致.

TCP中也是有很多参数要进行协商的,往往是以 " 选项 " 部分来体现的.

选项 : 最少0字节,最多40字节(TCP报头总长最多60,去掉前面固定的20,还剩下40.

其中有一个信息是挺关键的,TCP通信的序号,起始值.

TCP一次通信的过程中,序号不是从0或者1开始的,而是先选择一个比较大的数字,以这个数字的开头来计算

即使是同一个客户端和服务器,每次连接,开始的序号都是不同的.

如上图

在网络通信过程中,是有可能会后发先至的,这就有可能导致第一次连接的数据,再断开连接,第二次连接建立的时候才到达.

而每次开始的序号不同,就可以让客户端服务器鉴别出不是本次通信的数据.

三、四次挥手

断开连接,四次挥手->  正常情况下        (   断开连接不一定是四次挥手)

连接本质上就是让通信双方保存对方的信息

每个客户端/服务器,都要保存很多的对端信息.

一旦多了,就需要使用 " 数据结构 " 

断开连接的本质目的,就是为了把对端的信息,从数据结构中给删除掉/释放掉.

fin=>finish( 结束 )

四次挥手,不一定非得是客户端先发fin,服务器也可能先发fin.

调用socket.close()就会触发FIN(FIN也是由系统内核完成的)

如果进程直接结束,也会触发FIN

四、状态的切换

连接管理过程中,涉及到了TCP状态的切换.

状态描述的是某个实体,现在在干嘛.

TCP服务器和客户端都要有一定的数据结构来保存这个连接信息.

在这个数据结构中其中就有一个属性叫做 " 状态 "

操作系统内核根据状态的不同,决定当前应该干什么.

LISTEN状态:表示服务器这边创建好serverSocket了,并且绑定端口号完成了.

ESTABLISHED:已确定的,客户端和服务器连接已经建立完毕,(三次握手完成了)

CLOSE_WAIT:接下来代码中需要调用close来主动发起FIN   (   收到FIN进入这个状态)

TIME_WAIT:表示本端给对方发起FIN之后,对端也要给我发FIN,此时本段进入TIME_WAIT给最后一个ACK的重传留有一定的时间.   (   主动断开连接,发送FIN进入这个状态   )

如果发现服务器上出现大量CLOSE_WAIT,可能是代码中忘记关闭socket.

TIME_WAIT存在的意义,主要是防止最后一个ACK丢包.

如果服务器没有收到最后一个ACK,就会进行重传.

TIME_WAIT也不会无休止的等待,他也有一个时间上限.

五、滑动窗口

滑动窗口,是TCP中非常有特点的机制.

确认应答,超时重传,连接管理  => 可靠传输

可靠传输,其实付出了代价 -> 传输效率,单位时间,能传输的数据量变少了.

确认应答机制,每次发送方收到一个ACK才会发送下一个数据,这使得消耗大量的时间来等待ACK,此处消耗的时间是非常多的.

滑动窗口的提出,就是为了解决这种问题,滑动窗口可以保证可靠传输的基础上,提高效率,虽然通过这个机制提高,但是效率不可能高于UDP这种不需要可靠性的.但是比什么都不做有所提升.

引入了滑动窗口,批量传输.把多次请求的等待时间,使用同一份时间来等,减少了总等待时间.

1001到5001,这四分数据已经批量传出去了,传输出这四份数据之后,就等待ack,暂时先不传了.

就把白色的区域称为 " 窗口大小 "

批量发送了四个数据,就会对应四个ACK,此时四个ACK的到达顺序也不一定是同时到达,而是有先有后.

这时候就等待ACK,接收到一个ACK就再发送一个数据.

这种发送/返回ACK的速度都很快,直观上就感觉像是滑动的效果.

所以上述的过程就被称为了滑动窗口.

如果滑动窗口中出现丢包,滑动窗口会怎么样呢?

1. ACK丢了

比如说,数据都收到了,但是1001的ACK丢了,但是2001的ACK没丢,这时候不会有什么影响.

因为2001的ACK就包含了1001ACK的内容,告诉另一方1001之前的内容也收到了.

2. 数据丢了

数据丢了,不然要进行重传.

比如,如果说1001的数据丢了,那么后面发送的ACK都会从1001开始,告诉另一方1001到2000的数据丢了,还没有收到.

在上述重传的过程中,整体的效率是非常高的,这里的重传做到了 " 针对性" 的重传,哪个丢了就重传哪个,已经收到的数据,是不必重复发送的.

整体效率没有额外损失的,就把这种重传称为 " 快速重传 ".

确认应答    超时重传    滑动窗口   快速重传   并不冲突,而且是同时存在的.

如果当前传输过程是按照滑动窗口,就按照快速重传保证可靠性,此时判定丢包的标准就是看连续有多个ACK索要同一个数据.

如果当前传输过程不是按照滑动窗口,此时仍然按照超时重传保证可靠性,此时判定丢包的标准是达到超时时间还没有ACK到达.

滑动窗口中也有确认答应,只不过,把等待策略稍作调整,转成批量的了.

批量的前提是,短时间内发送了很多.

如果数据太少,此时窗口滑动不起来,就退化成了确认应答.

六、流量控制

通过滑动窗口可以提高传输效率,窗口大小越大,更多的数据服用同一块时间等待,效率就更高.

( 批量传多少数据不需要等待ACK,此时数据的量就称为 " 窗口大小 "

窗口大小不能无限大,数据发送的速度不能无限大,接收方的缓冲区是有大小的,缓冲区如果满了,就会发生丢包的情况.

就好像一个蓄水池一样,当蓄水速度超过放水速度,就有可能倒是水池满了

所以速度太快就会导致缓冲区被填满,导致丢包.如果缓冲区满了,丢的包就算重传也没有,反而会浪费硬件资源.

与其让接收方满了,你不发,不如提前感知到就减慢速度,让发送方发送的速度和接收方处理数据的速度能一致.

就是让接收方反过来控制发送方的速度.

通过这个字段来个发送方反馈发送速度.

这个字段再普通报文中无意义,再ACK报文中才有意义.

通过这个大小反馈给发送方接下来要发送的窗口设置成多少合适.

接收方就会按照自己接收缓冲区剩余空间的大小,作为ACK中的窗口大小的数值,下一步发送方就会根据这个数值来调整自己的窗口大小.

这个16位窗口,大小是否就是64位?

TCP报头的选项中,还包含了一个参数,叫做窗口扩展因子.

实际上要设置的窗口大小是16位窗口大小*2^窗口扩展因子.