协议格式
IPv4
IP首部中的校验和只覆盖IP的首部,不覆盖IP数据报中的任何数据。
IP层会丢弃传输中损坏的数据报,但是不产生错误消息,由上层去检测和重传。但是如果发生了分片,IP层应该能保证原子性。
在IP层下面的每一种数据链路层都有自己的帧格式,其中包括帧格式中的数据字段的最大长度,即最大传送单元 MTU (Maximum Transfer Unit)。当一个数据报封装成链路层的帧时,此数据报的总长度(即首部加上数据部分)最好不能超过下面的数据链路层的MTU值,否则要分片。
增加首部的可变部分是为了增加IP数据报的功能,但这同时也使得IP数据报的首部长度成为可变的。这就增加了每一个路由器处理数据报的开销,实际上这些选项很少被使用。新的IP版本IPv6就将IP数据报的首部长度做成固定的。
IP包中只有首部检验和,由TCP和UDP报文各自包含自身的数据校验和。
IPv6
IPv6的区别
-
首部长度
首部长度可变,IPv4首部的选项字段允许IP首部被扩展,由此导致数据报首部长度可变,故不能预先确定数据字段从何开始,同时也使路由器处理一个IP数据报所需时间差异很大(有的要处理选项,有的不需要)。基于此,IPv6采用固定40字节长度的报头长度(称基本报头)。IPv6如何实现IPv4选项字段类似的功能,答案是扩展报头,并由IPv6基本报头的下一个首部指向扩展报头(如果有的话)。路由器不处理扩展报头,提升了路由器处理效率。 -
分片/重组
IPv6,分片与重组只能在源与目的地上执行,不允许在中间路由器进行。分片与重组是个耗时的操作,将该功能从路由器转移到端系统,大大加快了网络中的IP转发速率。那,如果路由器收到IPv6数据报太大而不能转发到出链路上怎么办?该路由器丢弃该包,并向发送发发回一个"分组太大"的ICMP差错报文,于是发送发使用较小长度的IP数据报重发数据。 -
首部检查和
IPv4中由于TTL的递减,所以每经过一个路由器都需要重新计算校验和,导致路由器处理速度的低下。加之,传输层和链路层协议执行了检验操作,网络传输可靠性提升,所以IPv6不进行首部检查和,从而更快速处理IP分组。(但在网络传输的过程中,链路层packet是可能损坏的,考虑到厂商设备的多样性和高负载。所以TCP校验应该是关键,如果发现checksum不对,TCP可以要求对方重传丢失的内容。)
TCP头
校验和是针对header和data计算出来的。TCP和UDP计算校验和时,都要加上一个12字节的伪首部。伪首部共有12字节,包含如下信息:源IP地址、目的IP地址、保留字节(置0)、传输层协议号(TCP是6)、TCP报文长度(报头+数据)。伪首部是为了增加TCP校验和的检错能力:如检查TCP报文是否收错了(目的IP地址)、传输层协议是否选对了(传输层协议号)等。
TCP和UDP的报文都没有一个字段可以表明自身长度,这个长度是由IP包中的总长度来记录的。
- TCP首部长度:由于TCP首部包含一个长度可变的选项部分,所以需要这么一个值来指定这个TCP报文段到底有多长。或者可以这么理解:就是表示TCP报文段中数据部分在整个TCP报文段中的位置。该字段的单位是32位字,即:4个字节。
- 选项部分:其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示,那么选项部分最长为:(2^4-1)*4-20=40字节(但要全零填充为4字节的整数倍)。
- 选项部分的应用:
- MSS最大报文段长度(Maxium Segment Size):指明数据字段的最大长度,数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS值指示自己期望对方发送TCP报文段时那个数据字段的长度。通信双方可以有不同的MSS值。如果未填写,默认采用536字节。MSS只出现在SYN报文中。即:MSS出现在SYN=1的报文段中。
- 窗口扩大选项(Windows Scaling):由于TCP首部的窗口大小字段长度是16位,所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生(如卫星通信),需要更大的窗口来满足性能和吞吐率,所以产生了这个窗口扩大选项。
- SACK选择确认项(Selective Acknowledgements):用来确保只重传缺少的报文段,而不是重传所有报文段。比如主机A发送报文段1、2、3,而主机B仅收到报文段1、3。那么此时就需要使用SACK选项来告诉发送方只发送丢失的数据。那么又如何指明丢失了哪些报文段呢?使用SACK需要两个功能字节。一个表示要使用SACK选项,另一个指明这个选项占用多少字节。描述丢失的报文段2,是通过描述它的左右边界报文段1、3来完成的。而这个1、3实际上是表示序列号,所以描述一个丢失的报文段需要64位即8个字节的空间。那么可以推算整个选项字段最多描述(40-2)/8=4个丢失的报文段。
- 时间戳选项(Timestamps):可以用来计算RTT(往返时间),发送方发送TCP报文时,把当前的时间值放入时间戳字段,接收方收到后发送确认报文时,把这个时间戳字段的值复制到确认报文中,当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS,也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示,每2^32个序列号就会产生回绕,那么使用时间戳字段就很容易区分相同序列号的不同报文。
- NOP(NO-Operation):它要求选项部分中的每种选项长度必须是4字节的倍数,不足的则用NOP填充。同时也可以用来分割不同的选项字段。如窗口扩大选项和SACK之间用NOP隔开。
UDP
UDP数据报格式有首部和数据两个部分。首部很简单,共8字节。包括:
- 源端口(Source Port):2字节,源端口号。
- 目的端口(Destination Port ):2字节,目的端口号。
- 长度(Length):2字节,UDP用户数据报的总长度,以字节为单位。
- 检验和(Checksum):2字节,用于校验UDP数据报的数字段和包含UDP数据报首部的“伪首部”。其校验方法同IP分组首部中的首部校验和。
伪首部,又称为伪包头(Pseudo Header):是指在TCP的分段或UDP的数据报格式中,在数据报首部前面增加源IP地址、目的IP地址、IP分组的协议字段、TCP或UDP数据报的总长度等共12字节,所构成的扩展首部结构。此伪首部是一个临时的结构,它既不向上也不向下传递,仅仅只是为了保证可以校验套接字的正确性。
UDP的校验和是可选的,如果校验码为 0 ,意味着发送者末产生校验码。这表示对于数据段不使用校验,因为 IP 只是对 IP 首部进行校验。
RST
产生复位的一种常见情况是当连接请求到达时,目的端口没有进程正在监听。对于UDP,当一个数据报到达目的端口时,该端口没在使用,它将产生一个ICMP端口不可达的信息。而TCP则使用复位/重置连接。
RST报文段不会导致另一端产生任何响应,另一端根本不进行确认。收到RST的一方将终止该连接,并通知应用层连接复位。
带外数据SO_OOBINLINE
其实就是一个指针指向正常数据中的一个字节的后一个字节位置。
别用TCP的紧急数据提到带外数据已经不建议使用。同时提到带外数据可以用于控制意图,这样就不用像FTP一样得单独开一个控制连接了。
TCP的紧急指针,一般都不建议使用,而且不同的TCP/IP实现,也不同,一般说如果你有紧急数据宁愿再建立一个新的TCP/IP连接发送数据,让对方紧急处理。但是,虽然sendUrgentData的参数data是int类型,但只有这个int类型的低字节被发送,其它的三个字节被忽略。
接收端如何处理这个数据存在一些模糊。有的平台和API把它和平常数据分开处理,然后大多数解决方案是把它放到普通数据队列,让应用自己去从队列中获取处理。
一些TCP参数
tcp_max_syn_backlog
建立连接涉及两个队列:
半连接队列,保存SYN_RECV状态的连接。队列长度由net.ipv4.tcp_max_syn_backlog设置。
accept队列,保存ESTABLISHED状态的连接。队列长度为min(net.core.somaxconn, backlog)。其中backlog是我们创建ServerSocket(intport, int backlog)时指定的参数,最终会传递给listen方法。
TCP SOCKET中backlog参数的用途是什么?
在linux 2.2以前,backlog大小包括了半连接状态和全连接状态两种队列大小。linux 2.2以后,分离为两个backlog来分别限制半连接SYN_RCVD状态的未完成连接队列大小跟全连接ESTABLISHED状态的已完成连接队列大小。互联网上常见的TCP SYN FLOOD恶意DOS攻击方式就是用/proc/sys/net/ipv4/tcp_max_syn_backlog来控制的。
在使用listen函数时,内核会根据传入参数的backlog跟系统配置参数/proc/sys/net/core/somaxconn中,二者取最小值,作为“ESTABLISHED状态之后,完成TCP连接,等待服务程序ACCEPT”的队列大小。在kernel 2.4.25之前,是写死在代码常量SOMAXCONN,默认值是128。在kernel 2.4.25之后,在配置文件/proc/sys/net/core/somaxconn (即 /etc/sysctl.conf 之类 )中可以修改。
How TCP backlog works in Linux
backlog为0 时在linux上表明允许不受限制的连接数,这是一个缺陷,因为它可能会导致SYN Flooding(拒绝服务型攻击。
tcp_tw_recycle :BOOLEAN
默认值是0。
打开快速 TIME-WAIT sockets 回收。除非得到技术专家的建议或要求﹐请不要随意修改这个值。(做NAT的时候,建议打开它)。
tcp_tw_reuse:BOOLEAN
默认值是0。
该文件表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接(这个对快速重启动某些服务,而启动后提示端口已经被使用的情形非常有帮助)。
tcp_max_orphans :INTEGER
缺省值是8192。
系统所能处理不属于任何进程的TCP sockets最大数量。假如超过这个数量﹐那么不属于任何进程的连接会被立即reset,并同时显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要依赖这个或是人为的降低这个限制(这个值Redhat AS版本中设置为32768,但是很多防火墙修改的时候,,议该值修改为2000)。
tcp_abort_on_overflow :BOOLEAN
缺省值是0。
当守护进程太忙而不能接受新的连接,就向对方发送reset消息,默认值是false。这意味着当溢出的原因是因为一个偶然的猝发,那么连接将恢复状态。只有在你确信守护进程真的不能完成连接请求时才打开该选项,该选项会影响客户的使用。(对待已经满载的sendmail,apache这类服务的时候,这个可以很快让客户端终止连接,可以给予服务程序处理已有连接的缓冲机会,所以很多防火墙上推荐打开它)。
TCP_NODELAY
Nagle’s Algorithm 是为了提高带宽利用率设计的算法,其做法是合并小的TCP 包为一个,避免了过多的小报文的 TCP 头所浪费的带宽。如果开启了这个算法 (默认),则协议栈会累积数据直到以下两个条件之一满足的时候才真正发送出 去:
- 积累的数据量到达最大的 TCP Segment Size。
- 收到了一个 Ack。
TCP Delayed Acknoledgement 也是为了类似的目的被设计出来的,它的作用就是延迟 Ack 包的发送,使得协议栈有机会合并多个 Ack,提高网络性能。
如果一个 TCP 连接的一端启用了 Nagle‘s Algorithm,而另一端启用了 TCP Delayed Ack,而发送的数据包又比较小,则可能会出现这样的情况:发送端在等待接收端对上一个packet 的 Ack 才发送当前的 packet,而接收端则正好延迟了 此 Ack 的发送,那么这个正要被发送的 packet 就会同样被延迟。当然 Delayed Ack 是有个超时机制的,而默认的超时正好就是 40ms。
现代的 TCP/IP 协议栈实现,默认几乎都启用了这两个功能,你可能会想,按我上面的说法,当协议报文很小的时候,岂不每次都会触发这个延迟问题?事实不是那样的。仅当协议的交互是发送端连续发送两个 packet,然后立刻 read 的时候才会出现问题。
Nagle算法主要是避免发送小的数据包,要求TCP连接上最多只能有一个未被确认的小分组,在该分组的确认到达之前不能发送其他的小分组。相反,TCP收集这些少量的小分组,并在确认到来时以一个分组的方式发出去。
SO_LINGER
设置函数close()关闭TCP连接时的行为。缺省close()的行为是,如果有数据残留在socket发送缓冲区中则系统将继续发送这些数据给对方,等待被确认,然后返回。SO_LINGER选项用来改变此缺省设置。使用如下结构:
1 | struct linger { |
l_onoff | l_linger | closesocket行为 | 发送队列 | 底层行为 |
---|---|---|---|---|
零 | 忽略 | 立即返回。 | 保持直至发送完成。 | 系统接管套接字并保证将数据发送至对端。 |
非零 | 零 | 立即返回。 | 立即放弃。 | 直接发送RST包,自身立即复位,不用经过2MSL状态。对端收到复位错误号。 |
非零 | 非零 | 阻塞直到l_linger时间超时或数据发送完成。(套接字必须设置为阻塞) | 在超时时间段内保持尝试发送,若超时则立即放弃。 | 超时则同第二种情况,若发送完成则皆大欢喜。 |
第二种设置主要是为了避免主动断开连接方进入TIME_WAIT状态。丢失缓冲区中未丢失数据只是一种副作用。
SO_REUSEADDR / SO_REUSEPORT
浅析套接字中SO_REUSEPORT和SO_REUSEADDR的区别
SO_KEEPALIVE
貌似是由发起连接方(客户端)主动发给服务端的,就是一个data size为0的packet,服务器收到这个packet也会回复一个同样data size为0的packet表明连接仍存活。
SO_KEEPALIVE和心跳线程
SO_KEEPALIVE是系统底层的机制,用于系统维护每一个tcp连接的。
心跳线程属于应用层,主要用于终端和服务器连接的检查。
即使SO_KEEPALIVE检测到连接正常,但并不能保证终端和服务器连接的正常。有一种情况,服务器进程死了,但它和客户端的tcp连接还连着(该连接由系统维护的)。
这就是SO_KEEPALIVE不能取代心跳线程的原因吧。
TCP协议
四次挥手
其实也可以看成两次过程,任何一方发送FIN表明自己不会再发送数据。
TIME_WAIT(涉及主动断开连接一方)
TCP协议在关闭连接的四次握手过程中,最终的ACK 是由 主动关闭连接 的一端(后面统称A端)发出的,如果这个ACK丢失,对方(后面统称B端)将重发出最终的FIN,因此A端必须维护状态信息(TIME_WAIT)允许它重发最终的ACK。如果A端不维持TIME_WAIT状态,而是处于CLOSED 状态,那么A端将响应RST分节,B端收到后将此分节解释成一个错误(在java中会抛出connection reset的SocketException)。
因而,要实现TCP全双工连接的正常终止,必须处理终止过程中四个分节任何一个分节的丢失情况,主动关闭连接的A端必须维持TIME_WAIT状态。
主动关闭的一方要负责处于TIME_WAIT状态中。MSL就是maximum segment lifetime(最大分节生命期),这是一个IP数据包能在互联网上生存的最长时间,超过这个时间IP数据包将在网络中消失 。MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传统上使用30秒。Windows使用的是2分钟,而Linux则是30秒。
CLOSE_WAIT(涉及被动断开连接一方)
在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。
出现大量CLOSE_WAIT的现象,主要原因是某种情况下对方关闭socket链接,但是我方忙与读或者写,没有关闭连接。代码需要判断socket,一旦读到0,断开连接,read返回负,检查一下errno,如果不是AGAIN,就断开连接。
服务器TIME_WAIT和CLOSE_WAIT详解和解决办法
拥塞控制
当cwnd<ssthresh时,使用慢开始算法。
当cwnd>ssthresh时,改用拥塞避免算法。
当cwnd=ssthresh时,慢开始与拥塞避免算法任意。
快重传和快恢复
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
快重传配合使用的还有快恢复算法,有以下两个要点:
- 当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半。但是接下去并不执行慢开始算法。
- 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法。如下图:
随机早期检测RED
若发生路由器的尾部丢弃,可能影响到很多条TCP连接,结果就是这许多的TCP连接在同一时间进入慢开始状态。这在术语中称为全局同步。全局同步会使得网络的通信量突然下降很多,而在网络恢复正常之后,其通信量又突然增大很多。
为避免发生网路中的全局同步现象,路由器采用随机早期检测(RED:randomearly detection)。
msl、ttl及rtt的区别
- MSL 是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。例如RIP协议用经过的最大路由节点数作为MSL。
- IP头中有一个TTL域,TTL是 time to live的缩写,中文可以译为“生存时间”,这个生存时间是由源主机设置初始值但不是存的具体时间,而是存储了一个ip数据报可以经过的最大路由数,每经 过一个处理他的路由器此值就减1,当此值为0则数据报将被丢弃,同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。
TTL与MSL是有关系的但不是简单的相等的关系,MSL要大于等于TTL。 - RTT是客户到服务器往返所花时间(round-trip time,简称RTT),TCP含有动态估算RTT的算法。TCP还持续估算一个给定连接的RTT,这是因为RTT受网络传输拥塞程序的变化而变化。