【TCP/IP知识点总结】
作者:小教学发布时间:2023-09-28分类:程序开发学习浏览:64
TCP/IP知识点总结
- 一、TCP/IP
- 1.1 基础概念
- 1.2 IP 网际协议
- 二、ARP 地址解析协议
- 三、RARP 逆地址解析协议
- 四、ICMP Internet控制报文协议
- 五、IP选路
- 5.1 ip搜索路由表的步骤
- 5.2 选路机制和选路策略
- 5.3 路由表
- 5.4 动态选路
- 六、UDP 用户数据报协议
- 6.1 基础概念
- 6.2 IP分片
- 七、IGMP Internet组管理协议
- 八、DNS 域名系统
- 九、TFTP 简单文件传送协议 和BOOTP 引导程序协议
- 十、TCP 传输控制协议
- 10.1 TCP传输
- 10.2 标志位说明
- 10.3 三次握手
- 10.4 四次挥手(终止连接的四次握手)
- 10.5 最大报文段长度
- 10.6 半关闭
- 10.7 TCP状态图
- 10.8 TIME_WAIT
- 10.9 复位报文段(重新建立连接)
- 10.10 同时打开与同时关闭
- 10.11 TCP服务器端口号
- 10.12 伯克利的TCP呼入连接请求队列
- 10.13 交互数据流
- 10.14 滑动窗口协议
- 10.14.1 窗口左右边沿的运动
- 10.15 慢启动
- 10.16 TCP超时与重传
- 10.16.1 定时器
- 10.16.2 坚持定时器
- 10.16.3 保活定时器
学习的TCP/IP知识均来源于即时通讯网
一、TCP/IP
1.1 基础概念
- TCP/IP并非特指TCP和IP,而是指TCP/IP协议;
- TCP/IP共有4层,应用层,传输层,网络层,数据链路层;
- 传输层包含TCP,UDP;
- 网络层包含IP,ICMP,IGMP;
- 传输从上到下,分别加上TCP首部,IP首部,以太网首部和尾部;
- 通过以太网传输的比特流称作帧(Frame);
- MTU表示数据链路层可传输的最大值,如果IP传输的长度超过MTU就需要分片传输;
- IP不是一个可靠的协议,需要TCP是一个可靠的协议;
- 以太网是一种局域网技术,并通过物理层和数据链路层实现数据的传输
1.2 IP 网际协议
- ip首部长固定为20个字节,除非有选项字段;
- ip首部有4位首部长度,指首部占32 bit字的数目,也就是4字节(B/byte)得数目,由于4位bit表示得数据为0-15,所以最大的IP首部长为15*4=60字节,一般来讲,普通IP数据报(没有选项)字段首部长度值为5,也就是20个字节;
- ip首部有8位服务类型(TOS),包括3bit优先权子字段(已被忽略),4bit的TOS子字段和1bit未用但是必须为0,4bit的TOS分别代表:最小时延、最大吞吐量、最高可靠性和最小费用。4bit中只能置其中1bit(同时只能有一个为1)。如果所有4bit均为0,那么就意味着是一般服务;
- ip首部有16位总长度(字节数),指整个IP数据报的长度,以字节为单位。利用首部长度字段和总长度字段,就可以知道IP数据报中数据内容的起始位置和长度,16位表示的最大数为2^16-1=65535字节,主机一般要求不能接收超过576字节的数据报,UDP的应用(RIP,TFTP,BOOTP,DNS,以及SNMP),它们都限制用户数据报长度为512字节,小于576字节,实际上现在大多数的实现(特别是那些支持网络文件系统NFS的实现)允许超过8192字节的IP数据报。
- 数据链路(如以太网)需要填充一些数据以达到最小长度。尽管以太网的最小帧长为64字节,但是IP数据可能会更短;
- ip首部有16位标识字段,唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1;
- ip首部有8位TTL字段,TL(time-to-live)生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置(通常为32或64),一旦经过一个处理它的路由器,它的值就减去1。当该字段的值为0时,数据报就被丢弃,并发送ICMP报文通知源主机;
- ip首部有8位协议字段,1表示为ICMP协议,2表示为IGMP协议,6表示为TCP协议,17表示为UDP协议。
- ip首部有16位校验和字段,IP首部计算的检验和码。它不对首部后面的数据进行计算,发送方:计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16 bit进行二进制反码求和(整个首部看成是由一串16 bit的字组成),结果存在检验和字段中。接收方:当收到一份IP数据报后,同样对首部中每个16 bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。如果结果不是全1(即检验和错误),那么IP就丢弃收到的数据报。但是不生成差错报文,由上层去发现丢失的数据报并进行重传。举例:例如发送方发送的首部为0001,那么它的校验和应该是1110,而接收方刚好计算除校验和的结果为1110,校验和字段取反就是0001,那么相加就全是1。
- ip首部始终是32bit的整数倍,如果采用选项字段,不够32bit则需要补充0。
- ip除网络号外的字节,通常会划分子网+主机号,主机需要通过子网掩码来确定多少bit用于子网号,多少bit用于主机号,掩码是32bit的值,其中值为1的比特留给网络号和子网号,为0的比特留给主机号;
- 如果知道本机的IP地址,那么就知道它是否为A类、B类或C类地址(从IP地址的高位可以得知,左边的最高位,也就是ip的第一个0-255,8位来确定),也就知道网络号和子网号之间的分界线。而根据子网掩码就可知道子网号与主机号之间的分界线。
- 通过ip地址和子网掩码,可以转换为2进制,按位与计算网络号和子网号,例如:IP地址:140.252.13.33,子网掩码:255.255.255.224,分别转换为2进制,10001100.11111100.00001101.00100001 和 11111111.11111111.11111111.11100000,可以明显看出主机号只有5位,按位与网络号和子网号结果为10001100.11111100.00001101.00100000也就是140.252.13.32,主机号从IP地址后5位得出为1。
二、ARP 地址解析协议
- 48bit的以太网地址用6个16进制的数来表示,中间以冒号隔开;
- ARP就是IP转以太网地址(mac地址);
- ARP的功能是在32 bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射。
- 以太网报头中的前两个字段是以太网的源地址和目的地址。目的地址为全1的特殊地址是广播地址。电缆上的所有以太网接口都要接收广播的数据帧;
- 两个字节长的以太网帧类型表示后面数据的类型。对于ARP请求或应答来说,该字段的值为0x0806
- 硬件类型字段表示硬件地址的类型。它的值为1即表示以太网地址。协议类型字段表示要映射的协议地址类型。它的值为0x0800即表示IP地址。它的值与包含IP数据报的以太网数据帧中的类型字段的值相同
- 两个1字节的字段,硬件地址长度和协议地址长度分别指出硬件地址和协议地址的长度,以字节为单位。对于以太网上IP地址的ARP请求或应答来说,它们的值分别为6和4
- 操作字段指出四种操作类型,它们是ARP请求(值为1)、ARP应答(值为2)、RARP请求(值为3)和RARP应答(值为4)。这个字段必需的,因为ARP请求和ARP应答的帧类型字段值是相同的
- 接下来的四个字段是发送端的硬件地址(在本例中是以太网地址)、发送端的协议地址(IP地址)、目的端的硬件地址和目的端的协议地址。注意,这里有一些重复信息:在以太网的数据帧报头中和ARP请求数据帧中都有发送端的硬件地址
- 单词arp或ip后面的值60指的是以太网数据帧的长度。由于ARP请求或回答的数据帧长都是42字节(28字节的ARP数据,14字节的以太网帧头),因此,每一帧都必须加入填充字符以达到以太网的最小长度要求:64字节。
三、RARP 逆地址解析协议
- RARP协议是许多无盘系统在引导时用来获取IP地址的。RARP分组格式基本上与ARP分组一致。一个RARP请求在网络上进行广播,它在分组中标明发送端的硬件地址,以请求相应IP地址的响应。应答通常是单播传送的。
- 具有本地磁盘的系统引导,一般是从磁盘的配置文件中读取IP地址
四、ICMP Internet控制报文协议
- ICMP经常被认为是IP层的一个组成部分。它传递差错报文以及其他需要注意的信息。ICMP报文通常被IP层或更高协议层(TCP或UDP)使用,一些ICMP报文把差错报文返回给用户进程, ICMP报文是在IP数据报内部被传输的。是Internet控制报文协议
- ICMP报文的前4个字节(32bit)都是一样的,但是剩下的其他字节则互不相同;
- ICMP既可以是查询报文,也可以是差错报文,不同类型由报文中的类型字段和代码字段来共同决定;
- ping操作测试另一台主机是否可达,也是ICMP报文的一种。
- 在某些传输协议中,如在以太网中,为了正确地识别每个字节的开始和结束,会在每个字节前添加一位起始位,在后面添加一位结束位。因此,每个字节实际上包含8位数据、1位起始位和1位结束位。理论上1字节=8bit
- ping是对两个TCP/IP系统连通性进行测试的基本工具。它只利用ICMP回显请求和回显应答报文,而不用经过传输层(TCP/UDP)
- Traceroute程序使用ICMP报文和IP首部中的TTL字段(生存周期)。因为TTL为0,且目的ip地址不是目的主机,则路由器丢弃该数据报,并发回一份超时ICMP报文,Traceroute程序发送一份UDP数据报给目的主机,但它选择一个不可能的值作为UDP端口号(大于30000),使目的主机的任何一个应用程序都不可能使用该端口。因为,当该数据报到达时,将使目的主机的UDP模块产生一份“端口不可达”错误(见6.5节)的ICMP报文。这样,Traceroute程序所要做的就是区分接收到的ICMP报文是超时还是端口不可达,以判断什么时候结束。
五、IP选路
5.1 ip搜索路由表的步骤
- 搜索匹配的主机地址;
- 搜索匹配的网络地址;
- 搜索默认表项(默认表项一般在路由表中被指定为一个网络表项,其网络号为0)。
5.2 选路机制和选路策略
IP层进行的选路实际上是一种选路机制,它搜索路由表并决定向哪个网络接口发送分组。这区别于选路策略,它只是一组决定把哪些路由放入路由表的规则。IP执行选路机制,而路由守护程序则一般提供选路策略。
5.3 路由表
- U 该路由可以使用。
- G 该路由是到一个网关(路由器)。如果没有设置该标志,说明目的地是直接相连的。
- H 该路由是到一个主机,也就是说,目的地址是一个完整的主机地址。如果没有设置该标志,说明该路由是到一个网络,而目的地址是一个网络地址:一个网络号,或者网络号与子网号的组合。
- D 该路由是由重定向报文创建。
- M 该路由已被重定向报文修改。
标志G是非常重要的,因为由它区分了间接路由和直接路由(对于直接路由来说是不设置标志G的)。其区别在于,发往直接路由的分组中不但具有指明目的端的IP地址,还具有其链路层地址。当分组被发往一个间接路由时,IP地址指明的是最终的目的地,但是链路层地址指明的是网关(即下一站路由器)。
H标志表明,目的地址(netstat命令输出第一行)是一个完整的主机地址。没有设置H标志说明目的地址是一个网络地址(主机号部分为0)。当为某个目的IP地址搜索路由表时,主机地址项必须与目的地址完全匹配,而网络地址项只需要匹配目的地址的网络号和子网号就可以了
5.4 动态选路
动态选路并不改变内核在IP层的选路方式。这种选路方式称为选路机制(routing mechanism)。内核搜索路由表,查找主机路由、网络路由以及默认路由的方式并没有改变。仅仅是放置到路由表中的信息改变了—当路由随时间变化时,路由是由路由守护程序动态地增加或删除,而不是来自于自引导程序文件中的route命令。
六、UDP 用户数据报协议
6.1 基础概念
- UDP是一个简单的面向数据报的运输层协议:进程的每个输出操作都正好产生一个UDP数据报,并组装成一份待发送的IP数据报
- TCP是面向流字符的协议不同,应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系
- UDP不提供可靠性:它把应用程序传给IP层的数据发送出去,但是并不保证它们能到达目的地
UDP首部如下
- 端口号表示发送进程和接收进程
- TCP端口号与UDP端口号是相互独立的
- UDP长度字段指的是UDP首部和UDP数据的字节长度
- IP数据报长度指的是数据报全长,UDP数据报长度是全长减去IP首部的长度
- UDP检验和覆盖UDP首部和UDP数据,UDP的检验和是可选的,而TCP的检验和是必需的。
6.2 IP分片
- IP把MTU与数据报长度进行比较,如果需要则进行分片。分片可以发生在原始发送端主机上,也可以发生在中间路由器上。
- 把一份IP数据报分片以后,只有到达目的地才进行重新组装(这里的重新组装与其他网络协议不同,它们要求在下一站就进行进行重新组装,而不是在最终的目的地)。
- 任何运输层首部只出现在第1片数据中。
- IP数据报是指IP层端到端的传输单元(在分片之前和重新组装之后),分组是指在IP层和链路层之间传送的数据单元。一个分组可以是一个完整的IP数据报,也可以是IP数据报的一个分片。
七、IGMP Internet组管理协议
- 支持主机和路由器进行多播的Internet组管理协议
- 正如ICMP一样,IGMP也被当作IP层的一部分。IGMP报文通过IP数据报进行传输
八、DNS 域名系统
- 域名系统(DNS)是一种用于TCP/IP应用程序的分布式数据库,它提供主机名字和IP地址之间的转换及有关电子邮件的选路信息。这里提到的分布式是指在Internet上的单个站点不能拥有所有的信息。每个站点(如大学中的系、校园、公司或公司中的部门)保留它自己的信息数据库,并运行一个服务器程序供Internet上的其他系统(客户程序)查询。DNS提供了允许服务器和客户程序相互通信的协议。
- DNS的一个基本特性是使用超高速缓存。即当一个名字服务器收到有关映射的信息(主机名字到IP地址)时,它会将该信息存放在高速缓存中。这样若以后遇到相同的映射请求,就能直接使用缓存中的结果而无需通过其他服务器查询
- 以点“.”结尾的域名称为绝对域名或完全合格的域名FQDN(Full Qualified DomainName)
九、TFTP 简单文件传送协议 和BOOTP 引导程序协议
- TFTP(Trivial File Transfer Protocol)即简单文件传送协议,为了保持简单和短小,TFTP将使用UDP。TFTP的代码(和它所需要的UDP、IP和设备驱动程序)都能适合只读存储器
- 服务器进程端口变化的原因是服务器进程不能占用这个熟知端口来完成需一些时间的文件传输(可能是几十秒甚至数分钟)。相反,在传输当前文件的过程中,这个熟知端口要留出来供其他的TFTP客户进程发送它们的请求
- 注意在TFTP分组中并不提供用户名和口令。这是TFTP的一个特征(即“安全漏洞”)。由于TFTP是设计用于系统引导进程,它不可能提供用户名和口令,TFTP的这一特性被许多解密高手用于获取Unix口令文件的复制,然后来猜测用户口令
- BOOTP使用UDP,它为引导无盘系统获得它的IP地址提供了除RARP外的另外一种选择。BOOTP还能返回其他的信息,如路由器的IP地址、客户的子网掩码和名字服务器的IP地址。
- BOOTP服务器比RARP服务器更易于实现,因为BOOTP请求和应答是在UDP数据报中,而不是特殊的数据链路层帧。一个路由器还能作为真正BOOTP服务器的代理,向位于不同网络的真正BOOTP服务器转发客户的BOOTP请求。
十、TCP 传输控制协议
10.1 TCP传输
TCP首部, TCP数据被封装在一个IP数据报中,TCP首部的数据格式。如果不计任选字段,它通常是20个字节
- 每个TCP段都包含源端和目的端的端口号,用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接,有时,一个IP地址和一个端口号也称为一个插口(socket)。
- 序号用来标识从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动,则TCP用序号对每个字节进行计数。序号是32 bit的无符号数,序号到达2^32-1后又从0开始。在每个TCP连接中,都有一个独立的序号生成器,它在连接开始时初始化为一个随机值。这个序号生成器每次发送一个新的TCP报文段时,都会递增该报文段的序号。因此,每个新的TCP报文段的序号都会比前一个报文段的序号大1。
- 发送一个SYN报文段到服务器,表示想要建立连接。在这个报文段中,SYN标志位被设为1,表示这是一个同步报文段,而序号字段则包含了客户端为该连接选择的初始序号(ISN)。这个初始序号是由客户端随机生成的,用于标识连接,该主机要发送数据的第一个字节序号为这个ISN加1
- 在TCP连接建立后,数据传输过程中,接收端会向发送端发送ACK报文段,以确认已成功接收到数据。在这个ACK报文段中,ACK标志位被设为1,表示这是一个确认报文段,而确认号字段则是接收端期望接收的下一个序号。
- TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此,连接的每一端必须保持每个方向上的传输数据序号。
10.2 标志位说明
- URG 紧急指针(urgent pointer)有效
- ACK 确认序号有效
- PSH 接收方应该尽快将这个报文段交给应用层
- RST 重建连接
- SYN 同步序号用来发起一个连接
- FIN 发端完成发送任务
10.3 三次握手
- 请求端(通常称为客户)发送一个SYN段指明客户打算连接的服务器的端口,以及初始序号(ISN,在这个例子中为1415531521)。这个SYN段为报文段1。
- 服务器发回包含服务器的初始序号的SYN报文段(报文段2)作为应答。同时,将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。
- 客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认(报文段3)。
10.4 四次挥手(终止连接的四次握手)
建立一个连接需要三次握手,而终止一个连接要经过4次握手。这由TCP的半关闭(halfclose)造成的。既然一个TCP连接是全双工(即数据在两个方向上能同时传递),因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN,它必须通知应用层另一端几经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。
- TCP客户端发送一个FIN,用来关闭从客户到服务器的数据传送。
- 当服务器收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一样,一个FIN将占用一个序号。
- 同时TCP服务器还向应用程序(即丢弃服务器)传送一个文件结束符。接着这个服务器程序就关闭它的连接,导致它的TCP端发送一个FIN
- 客户必须发回一个确认,并将确认序号设置为收到序号加1(报文段7)。
10.5 最大报文段长度
最大报文段长度(MSS)表示TCP传往另一端的最大块数据的长度。当一个连接建立时,连接的双方都要通告各自的MSS
10.6 半关闭
- 初始端发出的FIN,接着是另一端对这个FIN的ACK报文段
- 因为接收半关闭的一方仍能发送数据。我们只显示一个数据报文段和一个ACK报文段,但可能发送了许多数据报文段
- 当收到半关闭的一端在完成它的数据传送后,将发送一个FIN关闭这个方向的连接,这将传送一个文件结束符给发起这个半关闭的应用进程
- 当对第二个FIN进行确认后,这个连接便彻底关闭了
10.7 TCP状态图
10.8 TIME_WAIT
- TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)。它是任何报文段被丢弃前在网络内的最长时间
- 2MSL等待的另一个结果是这个TCP连接在2MSL等待期间,定义这个连接的插口(客户的IP地址和端口号,服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用
- TCP在重启动后的MSL秒内不能建立任何连接。这就称为平静时间(quiet time)。
- 在FIN_WAIT_2状态我们已经发出了FIN,并且另一端也已对它进行确认。除非我们在实行半关闭,否则将等待另一端的应用层意识到它已收到一个文件结束符说明,并向我们发一个FIN来关闭另一方向的连接。只有当另一端的进程完成这个关闭,我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。
10.9 复位报文段(重新建立连接)
- TCP首部中的RST比特是用于“复位”的
- 无论何时一个报文段发往基准的连接(referenced connection)出现错误,TCP都会发出一个复位报文段(这里提到的“基准的连接”是指由目的IP地址和目的端口号以及源IP地址和源端口号指明的连接)
- 产生复位的一种常见情况是当连接请求到达时,目的端口没有进程正在听,当一个数据报到达目的端口时,该端口没在使用,它将产生一个ICMP端口不可达的信息。而TCP则使用复位。
- 终止一个连接的正常方式是一方发送FIN。有时这也称为有序释放(orderly release),因为在所有排队数据都已发送之后才发送FIN,正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接。有时称这为异常释放(abortive release)。
- 异常终止一个连接对应用程序来说有两个优点:(1)丢弃任何待发数据并立即发送复位报文段;(2)RST的接收方会区分另一端执行的是异常关闭还是正常关闭。应用程序使用的API必须提供产生异常关闭而不是正常关闭的手段。
- 如果一方已经关闭或异常终止连接而另一方却还不知道,我们将这样的TCP连接称为半打开(Half-Open)的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据,仍处于连接状态的一方就不会检测另一方已经出现异常。
- 由于服务器失去了所有连接状态信息,当它重新连接上网络并接收到新的数据时,它只能发送RST报文来关闭这个连接。
10.10 同时打开与同时关闭
- 两个应用程序同时彼此执行主动打开的情况是可能的,尽管发生的可能性极小。每一方必须发送一个SYN,且这些SYN必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口。这又称为同时打开(simultaneous open)。
- 例如,主机A中的一个应用程序使用本地端口7777,并与主机B的端口8888执行主动打开。主机B中的应用程序则使用本地端口8888,并与主机A的端口7777执行主动打开。
- 一个同时打开的连接需要交换4个报文段,比正常的三次握手多一个。此外,要注意的是我们没有将任何一端称为客户或服务器,因为每一端既是客户又是服务器。
10.11 TCP服务器端口号
- 目的IP地址、目的端口号、源IP地址和源端口号来处理传入的多个连接请求。TCP仅通过目的端口号无法确定那个进程接收了一个连接请求。只有处于LISTEN的进程能够接收新的连接请求。处于ESTABLISHED的进程将不能接收SYN报文段,而处于LISTEN的进程将不能接收数据报文段。
- 限定的本地IP地址,这个连接请求将不会到达(除限定外的IP地址)服务器的应用程序,因为它根据应用程序中指定的本地IP地址被内核中的TCP模块拒绝;
- 限定的远端IP地址,TCP服务器必须不指明远端插口,而等待连接请求的到来,然后检查客户端的IP地址和端口号。
10.12 伯克利的TCP呼入连接请求队列
- 正等待连接请求的一端有一个固定长度的连接队列,该队列中的连接已被TCP接受(即三次握手已经完成),但还没有被应用层所接受。注意区分TCP接受一个连接是将其放入这个队列,而应用层接受连接是将其从该队列中移出
- 应用层将指明该队列的最大长度,这个值通常称为积压值(backlog)。它的取值范围是0~5之间的整数,包括0和5(大多数的应用程序都将这个值说明为5)。
- 当一个连接请求(即SYN)到达时,TCP使用一个算法,根据当前连接队列中的连接数来确定是否接收这个连接
- 如果对于新的连接请求,该TCP监听的端点的连接队列中还有空间,TCP模块将对SYN进行确认并完成连接的建立。但应用层只有在三次握手中的第三个报文段收到后才会知道这个新连接时。另外,当客户进程的主动打开成功但服务器的应用层还不知道这个新的连接时,它可能会认为服务器进程已经准备好接收数据了(如果发生这种情况,服务器的TCP仅将接收的数据放入缓冲队列)。
- 如果对于新的连接请求,连接队列中已没有空间,TCP将不理会收到的SYN。也不发回任何报文段(即不发回RST)。如果应用层不能及时接受已被TCP接受的连接,这些连接可能占满整个连接队列,客户的主动打开最终将超时
10.13 交互数据流
- 经受时延的ACK。通常TCP在接收到数据时并不立即发送ACK;相反,它推迟发送,以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象为数据捎带ACK)。绝大多数实现采用的时延为200 ms,也就是说,TCP将以最大200 ms的时延等待是否有数据一起发送。
- Nagle算法。该算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组,在该分组的确认到达之前不能发送其他的小分组。相反,TCP收集这些少量的分组,并在确认到来时以一个分组的方式发出去。该算法的优越之处在于它是自适应的:确认到达得越快,数据也就发送得越快。而在希望减少微小分组数目的低速广域网上,则会发送更少的分组
10.14 滑动窗口协议
- 将字节从1至11进行标号。接收方通告的窗口称为提出的窗口(offered window),它覆盖了从第4字节到第9字节的区域,表明接收方已经确认了包括第3字节在内的数据,且通告窗口大小为6,窗口大小是与确认序号相对应的。发送方计算它的可用窗口,该窗口表明多少数据可以立即被发送。
- 发送方不必发送一个全窗口大小的数据。
- 来自接收方的一个报文段确认数据并把窗口向右边滑动。这是因为窗口的大小是相对于确认序号的。
- 正如从报文段7到报文段8中变化的那样,窗口的大小可以减小,但是窗口的右边沿却不能够向左移动。
- 接收方在发送一个ACK前不必等待窗口被填满。在前面我们看到许多实现每收到两个报文段就会发送一个ACK。
- 由接收方提供的窗口的大小通常可以由接收进程控制,这将影响TCP的性能。
- 当接收方确认数据后,这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动:
10.14.1 窗口左右边沿的运动
- 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
- 当窗口右边沿向右移动时将允许发送更多的数据,我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。
- 当右边沿向左移动时,我们称之为窗口收缩。Host Requirements RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。第22.3节给出了这样的一个例子,一端希望向左移动右边沿来收缩窗口,但没能够这样做。
10.15 慢启动
- 慢启动为发送方的TCP增加了另一个窗口:拥塞窗口(congestion window),记为cwnd。当与另一个网络的主机建立TCP连接时,拥塞窗口被初始化为1个报文段(即另一端通告的报文段大小)。每收到一个ACK,拥塞窗口就增加一个报文段(cwnd以字节为单位,但是慢启动以报文段大小为单位进行增加)。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制,而通告窗口则是接收方使用的流量控制。
10.16 TCP超时与重传
10.16.1 定时器
- 重传定时器使用于当希望收到另一端的确认
- 坚持(persist)定时器使窗口大小信息保持不断流动,即使另一端关闭了其接收窗口
- 保活(keepalive)定时器可检测到一个空闲连接的另一端何时崩溃或重启
- 2MSL定时器测量一个连接处于TIME_WA IT状态的时间
10.16.2 坚持定时器
- TCP不对ACK报文段进行确认,TCP只确认那些包含有数据的ACK报文段。
- TCP从不放弃发送窗口探查,窗口探查包含一个字节的数据(序号为9217)。TCP总是允许在关闭连接前发送一个字节的数据
- 糊涂窗口综合症:少量的数据将通过连接进行交换,而不是满长度的报文段
- 措施:(1)接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口(可以为0),除非窗口可以增加一个报文段大小(也就是将要接收的MSS)或者可以增加接收方缓存空间的一半,不论实际有多少。(2)发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据:(a)可以发送一个满长度的报文段;(b)可以发送至少是接收方通告窗口大小一半的报文段;©可以发送任何数据并且不希望接收ACK(也就是说,我们没有还未被确认的数据)或者该连接上不能使用Nagle算法。
10.16.3 保活定时器
- TCP连接的双方都没有向对方发送数据,则在两个TCP模块之间不交换任何信息。例如,没有可以在其他网络协议中发现的轮询。这意味着我们可以启动一个客户与服务器建立一个连接,然后离去数小时、数天、数个星期或者数月,而连接依然保持。中间路由器可以崩溃和重启,电话线可以被挂断再连通,但是只要两端的主机没有被重启,则连接依然保持建立。
- 保活并不是TCP规范中的一部分,保活功能就是试图在服务器端检测到半开放的连接。
- 如果一个给定的连接在两个小时之内没有任何动作,则服务器就向客户发送一个探查报文段
探查报文段结果如下:
- 客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此连接,则定时器在交换数据后的未来2小时再复位。
- 客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务器将不能够收到对探查的响应,并在75秒后超时。服务器总共发送10个这样的探查,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。
- 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应,但是这个响应是一个复位,使得服务器终止这个连接。
- 客户主机正常运行,但是从服务器不可达。这与客户主机已经崩溃相同,因为TCP不能够区分2和4之间的区别,它所能发现的就是没有收到探查的响应。
- 程序开发学习排行
-
- 1鸿蒙HarmonyOS:Web组件网页白屏检测
- 2HTTPS协议是安全传输,为啥还要再加密?
- 3HarmonyOS鸿蒙应用开发——数据持久化Preferences
- 4记解决MaterialButton背景颜色与设置值不同
- 5鸿蒙HarmonyOS实战-ArkUI组件(RelativeContainer)
- 6鸿蒙HarmonyOS实战-ArkUI组件(Stack)
- 7鸿蒙HarmonyOS实战-ArkUI组件(GridRow/GridCol)
- 8[Android][NDK][Cmake]一文搞懂Android项目中的Cmake
- 9鸿蒙HarmonyOS实战-ArkUI组件(mediaquery)
- 最近发表
-
- WooCommerce最好的WordPress常用插件下载博客插件模块的相关产品
- 羊驼机器人最好的WordPress常用插件下载博客插件模块
- IP信息记录器最好的WordPress常用插件下载博客插件模块
- Linkly for WooCommerce最好的WordPress常用插件下载博客插件模块
- 元素聚合器Forms最好的WordPress常用插件下载博客插件模块
- Promaker Chat 最好的WordPress通用插件下载 博客插件模块
- 自动更新发布日期最好的WordPress常用插件下载博客插件模块
- WordPress官方最好的获取回复WordPress常用插件下载博客插件模块
- Img to rss最好的wordpress常用插件下载博客插件模块
- WPMozo为Elementor最好的WordPress常用插件下载博客插件模块添加精简版