目录
传输层
传输层包含的协议主要有TCP和UDP。
端口号:是一个整数,用于区分不同的进程,同一个协议上,同一时刻同一个机器上,一个端口只能被一个进程绑定;一个进程可以绑定多个端口。端口号通过2个字节的无符号整数表示,取值范围:0~65535,0比较特殊(表示随机设定空闲端口),一般不会使用,1 ~ 1023已经被预定好了的(有一些知名的服务器提前预定了这个端口,我们日常开发要避开这些端口号)
学习协议,主要是学习数据格式、报文格式。
UDP协议:
端口号:用2个字节表示
UDP报文长度:就是报头长度(8字节)+载荷长度
校验和:网络传输过程中很容易出现错误,校验和存在的目的是为了能够发现或者纠正错误,对于UDP来说只是发现,没有纠正
校验和的工作原理:
除了CRC之外,MD5和SHA1算法,
MD5的特点:
1、定长:无论输入的字符串多长,计算出的MD5结果都是固定长度
2、分散:输入的内容,哪怕只有一点点不同,得到的MD5值相差都很大
3、不可逆:根据输入的内容,计算MD5值非常简单,但是已知MD5的值还原出原始内容,理论上很难实现
TCP协议:
TCP的相关机制:
TCP的基本特点是有连接,可靠传输,面向字节流,全双工。可靠传输不能做到100%送达,只能尽可能让数据能够到达对方(能够感知对方是否收到数据,如果发现对方没有收到,会进行重试)
TCP协议的格式
32位序号:表示的是TCP数据报载荷中的第一个字节的序号,由于序号是递增的,知道第一个,后续的每一个序号也能够知道
32位确认序号:接收方收到的数据最后一个字节序号的下一个序号,例如,A传输数据给B,第一个字节序号是1,一共1000个字节,确认序号就是1001
4位首部长度:TCP的报头长度,长度可变单位是4字节
保留6位:以备不时之需,吸取了UDP报文字段长度不能扩展的教训
URG:和紧急指针配合使用,URG为1表示紧急指针生效
ACK:确认号是否有效
PSH:催促标志位,提示接收端应用程序立刻从TCP缓冲区把数据读走
PST:对方要求重新建立连接,把携带RST标识的称为复位报文段
SYN:请求建立连接,携带SYN的称为同步报文段
FIN:通知对方,本端要关闭了,携带FIN的称为结束报文段
16位窗口大小:体现了接收方缓冲区剩余空间大小,ack报文中才有效(ack为1),虽然是16位,但是可以通过选项,设置扩展因子来扩大范围
16位校验和:用于检验数据是否出错
16位紧急指针:标识哪些部分是紧急数据,根据紧急指针的偏移量,把指定位置的数据优先发送
选项:TCP报头变长的主要原因,选项,可以有也可以没有。选项中包含的“窗口扩展因子”,能够扩展窗口的大小
数据:传输的业务数据
TCP核心机制:
机制1:确认应答
感知对方是否收到,也就是要让对方告诉你一声:收到了~(发送应答报文acknowledge,简称ack)
有一个问题,如果发送多个数据,也就会返回多个应答报文,也就会出现后发先至的情况,后发送的数据先到达。给传输的数据进行编号,可以区分数据的先后,即使应答报文顺序出错,也能区分出来。
TCP是字节流的,每一个字节都有独立的编号,字节和字节之间是连续、递增的。按照字节编号就称为“TCP的序号”,在应答报文中针对之前收到的数据进行的编号就叫TCP的确认序号(序号是针对载荷来编号的,也就是要传输的数据,报头不参与编号)。
应答报文中,确认序号是最后一个字节的序号+1,应答报文的ack为1,普通报文的ack为0。如果是普通报文,确认序号是无效的;如果是应答报文,序号和确认序号都是有效的,应答报文的编号是另外一套编号体系,另外,应答报文是默认不带数据的。
机制2:超时重传
关于后发先至:TCP针对接收方收到的数据,会进行重新排序,确保应用程序获取到的数据和发送方发送的数据顺序是一致的。但是实际上,网络传输的过程不是一帆风顺的,有可能会出现丢包的情况。
丢包的原因:
- 数据传输过程中发生了比特翻转(0变1,1变0),接收方发现校验和出错,此时会把这个错误的数据包给丢弃
- 数据传输到某个结点时(路由器),该结点负载太高,发生堵车了,后面传输过来的数据就可能会被丢弃
TCP可以感知到是否丢包,如果丢包了就会重新再发一次。发送方收到应答报文,说明没有发生丢包,如果没有收到应答报文,发送方会给出一个时间限制(超时时间),在这个时间范围内仍然没有收到应答报文,那么就视为丢包。
丢包也有两种情况:
1、传输了数据,对方没有返回应答报文,
2、传输了数据,对方返回了应答报文,但是发送方没有收到,应答报文丢包了~此时发送方会重新发送数据。
接收方有一个缓冲区,收到的数据会进入缓冲区,后续再接收到数据,会根据序号在缓冲区中找到对应的位置(排序),如果发现某一段序号在缓冲区中存在了,这时会把重新收到的数据丢弃。
超时重传的超时时间设置:每多重传一次,超时时间的间隔会变大。重传达到一定次数时,TCP不会重新尝试重传
确认应答和超时重传共同构建了TCP可靠传输机制
机制3:连接管理(三次握手和四次挥手)
建立连接:三次握手
断开连接:四次挥手
次数就是网络通信的次数,握手、挥手就是发送不携带业务数据(没有载荷,只有报头)的数据包,起到打招呼的作用
三次握手
如图
主动的一方是客户端,所以客户端会先发送一个握手的请求,syn是synchronized的缩写,表示同步,不是加锁的synchronized,同步是客户端希望服务器和他统一步调,来完成后续的传输;ack是acknowledge的缩写,表示应答报文。
建立连接是双向的操作,A需要和B说:我想和你建立连接(A想保存B的信息),B也需要和A说:我想和你建立连接(B想保存A的信息)
为什么要三次握手?三次握手要解决什么问题?三次握手的意义?
主要有3个方面:
1、投石问路,初步验证通讯链路是否畅通,这是进行可靠传输的前提
2、确认通信双方各自的发送能力和接收能力是否都正常
3、让通信双方在进行通信之前,对通信过程中需要用到的关键参数进行协商。例如TCP通信时起始数据的序号,就是通过三次握手进行协商的,起始序号并不都是从1开始的。
对于B来说,如何区分是不是迟到的数据?每个连接都会协商好不同的起始序号,如果发现和起始序号和最近收到的数据的序号差别很大,就认为是迟到的数据
为啥是三次?四次、两次行不行?
4次可以的,把中间的ack和syn拆成两个,但是没有必要这样做效率低。2次不可行,无法完成通信双方针对各自发送能力和接收能力的验证。对于TCP来说必须是3次握手
TCP三次握手的原因总结:
1、投石问路,初步验证通讯链路是否畅通
2、确认通信双方各自的发送能力和接收能力是否都正常
3、协商重要的参数(例如TCP连接中的起始序号)
四次挥手
四次挥手是比较优雅的断开连接的方式,双方各自把对端的信息删除掉,断开连接主动的一方可以是客户端,也可以是服务器。
FIN为1表示结束报文。
通信双方各自给对方发送FIN,各种给对方返回ack。在三次握手中,中间两次是合并了,但是对于四次挥手来说,中间的两次大概率不能合并,大部分情况是不能合并的。
对于三次握手:syn和ack都是在操作系统内核中完成的,由操作系统负责进行,时机都是在收到syn之后,这两个可以合并
对于四次挥手:ack是内核操控的,FIN的触发是通过应用程序调用close或者进程退出触发的。也就是说FIN触发的时机和程序员的代码有关系。socket.close() ==>系统内部发送FIN。ack和FIN两次的时机是不同的,如果close之前的代码耗时比较长,发送FIN也会比较晚一点。
机制4:滑动窗口
TCP是可靠传输的,但是可靠传输是有代价的,可靠传输降低了传输的效率。TCP希望能在可靠传输的基础上,还能够有一个不错的传输旋律,所以引入了滑动窗口。虽然有了滑动窗口,但是也不能让TCP的传输效率比UDP高。
如果出现了丢包,怎么办?
有两种情况:
1、数据包已经抵达,但是ack没有
此时不需要任何处理,批量发送数据,是有多个ack的,只是丢一部分,不可能全丢。如果1001ack丢了,但是2001ack达到了,2001ack能够涵盖1001ack
2、数据包丢了
1001~ 2000数据包丢了,B返回确认序号1001,接下来B都是返回确认序号1001,A连续收到多个1001的ack后,意识到1001~ 2000数据丢失了,于是会重新发送1001~ 2000的数据。当B收到1001~2000的数据后,B会发送7001(因为2001 ~ 7000的数据已经发过了)的ack。上述过程,能快速的识别哪个数据包丢失,并且针对性重传,其他顺利到达的数据无需重传,这个过程称为快速重传
机制5:流量控制
滑动窗口的窗口大小不能无限大,如果发送方发送的速度过快,而接收方处理数据的能力较弱,会使得接收缓冲区变满,此时发送方又强行发送数据,就会丢包。接收方的处理能力反向制约发送方的发送速度,就是流量控制。
接收方收到数据之后,会把缓冲区剩余空间大小通过ack反馈给发送方,接下来发送方可以依据缓冲区剩余空间大小来设置窗口大小,控制发送速度。
核心机制6:拥塞控制
拥塞控制也是控制发送方的发送速度,拥塞控制是站在传输链路的视角来限制发送方的发送速度
如上图,假设B的处理速度很快,A也不能无限速度发送,因为中间的链路可能顶不住,如果中间某个结点负载很高,A还是以很快的速度发送,这个结点就可能会出现丢包的情况。
中间结点很多,每次传输数据的路线也不一样,哪个结点顶不住,也不容易知道,而且中间结点还有别的设备的数据,如何衡量发送速度?面多加水,水多加面!如果发现不丢包,那就加快发送速度,如果发现丢包了,那就减慢发送速度。
流量控制和拥塞控制都会限制发送窗口的大小,这两个机制会同时起作用,根据这两个机制得出的最小的值作为实际的发送窗口。
核心机制7:延时应答
延时应答是为了提升传输的效率。
注意,上述过程中,延迟一些时间,不一定能够让返回ack的窗口大一点,如果应用程序不是一直在读取数据,或者延迟的时间内发送方又发送数据过来,那么窗口就不是大一点了~
核心机制8:捎带应答
捎带应答是在延时应答的基础上,引入的提升效率的机制。把返回的业务数据和ack合并在一起了。正常情况下,ack和业务数据是不能合并的,但是有了延时应答,ack返回的时间就会延后,就可能刚好赶上接下来要发送响应数据的操作,于是可以在发送响应数据的同时,把ack也带上
核心机制9:面向字节流
粘包问题:通过面向字节流的方式传输数据,都会涉及到粘包问题,粘的是TCP携带的载荷(应用层数据包)。应用层数据包在TCP缓冲区中,连成一片,粘在一起,就称为粘包问题。例如
A发送了3次数据,分别是111,222,333,由于TCP是面向字节流的,应用程序读取数据有很多种读法,11、12、22、333,111、22、2333等,但是111、222、333才是完整的数据包。要解决粘包问题,关键是明确数据包之间的边界。例如约定 "\n"是数据包之间的分隔符。
核心机制10:异常处理
1、进程崩溃:
进程崩溃在Java中的体现就是抛出了异常,但是没有catch,这个异常最终到了JVM,JVM会让进程直接崩溃。这种情况操作系统会进行善后处理:当进程崩溃的时候,进程中的PCB要被回收,PCB中的文件描述符表中对应的所有文件都会被系统自动关闭,Socket文件也会触发正常的关闭流程(也就是TCP4次挥手)
2、主机关机:
也就是正常的关机流程,点击关机按钮,此时操作系统会先结束所有的进程,这个过程也会触发4次挥手。这里有两种情况
4次挥手很快,4次挥手已经结束了,关机才真正完成
4次挥手很慢,没来得及挥完就关机了,如图
3、主机掉电(拔电源)
接收方掉电:
发送方掉电:
4、网线断开
上述的10个机制只是TCP中常见的机制,不代表TCP只有10个机制。