深入解析TCP/IP协议族与TCP重传机制

时间：11-20 神话故事提交错误

大家好，关于深入解析TCP/IP协议族与TCP重传机制很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！

OSI模型应用层：为用户提供接口/软件，如浏览器、QQ、微信、钉钉等。使用的协议包括HTTP/HTTPS、OICQ、BT、SIP、STMP等。

应用层协议表示层

表示层会话层：主要用于会话管理（建立、维护、关闭、区分）

传输层：为了实现数据的可靠/不可靠传输，协议包括TCP/UDP等。

网络层：提供三层（路由器）寻址、IP地址、三层（路由器）通信功能、IP协议

链路层：提供二层（交换机）寻址、MAC地址、二层（交换机）通信功能、以太网协议

物理层：网络接口

物理层OSI（数据封装、传输和解封装）的实现过程：

OSI 实现过程

二、TCP/IP协议簇：

1、Ethernet协议（以太网协议）

以太网协议

2、ARP协议：

ARP 协议ARP 工作原理工作原理：每个终端设备都有一张IP_MAC 映射表，表中存储了同网段已通信的其他终端设备对应的IP MAC地址，第一次通信时，由于这张表中没有对方的MAC地址，只能获取到IP地址，所以链路层的封装无法进行，所以需要获取MAC地址对方的。这时ARP协议就发挥作用了。当发现没有MAC地址时，就会发送ARP请求，其中包含对方的IP地址、自己的IP地址和MAC地址。这是一种全球广播的形式，即所有联网的终端都可以接收到。如果不是您自己的IP 地址，请忽略此消息。如果是您，则回复单向广播（ARP Reply）以回复您自己的MAC 地址。收到回复后，将其写入IP_MAC映射表中，下次通信时可以直接使用。

如果不在同一网段，则终端设备需要将目标IP与网关的MAC地址（通过ARP广播获取）进行绑定封装。如果网关发现目标IP不是自己的，就会通过路由表寻找目标路由上的下一个网关。 ARP广播同样得到下一个网关的MAC，然后以自己的MAC地址作为源MAC地址，下一个网关的MAC地址作为目标MAC地址，将数据发送给下一个网关。通过这样的循环，直到找到目标IP的MAC地址，最后将数据发送给目标。

扩张：

ARP请求报文ARP回复报文ARP攻击：第三方收到ARP广播后，将自己的MAC地址回复给对方。通过多次回复，覆盖真实的MAC地址，从而实现数据拦截。

ARP 中间人攻击

3、IP协议：

IP 协议IP 协议内容结构路由器在传输IP 协议数据的过程中，可能会经过几台路由器进行循环传输，始终无法到达对方，从而造成浪费网络资源。为了防止这种情况，设置了TTL时间参数，最大为255，如果一次不传则减1，如果为0则数据被丢弃。

Time to live（最大255跳）协议号（标记上层协议）头验证是为了防止数据被第三方篡改

头验证数据在网络传输过程中，会有一个数据大小的限制，即MTU。当发送的数据大于MTU时，需要进行分片。分段是IP 协议的一部分。共有三个参数用于标记分片，主要是为了保证由分片组装而成的数据的完整性。

IP分片

4、ICMP协议：

ICMP协议定义了ping的原理ICMP请求包ICMP回复包Tracert原理（windows）原理：Tracert也是不停地ping对方，但是每个IP包的TTL值从1逐渐增加，为0 ，中间设备会返回一个超时报文，其中携带设备IP，直到目标IP设备收到消息并回复应答报文。在unix或linux系统中，传输层使用UDP协议。

UDP和DHCP协议：

UDP对应的端口号UDP

DHCP协议：

DHCP协议定义DHCP协议原理DHCP协议抓包DCHP总结

TCP协议：

TCP定义TCP函数TCP头TCP头注意上图中四个非常重要的事情：

Sequence Number是数据包的序列号，用于解决网络数据包重排序的问题。

确认号为ACK——，用于确认收到，解决不丢包问题。

Window又称为Advertized-Window，也就是著名的滑动窗口（Sliding Window），用于解决流量控制。

TCP Flag，即数据包的类型，主要用于控制TCP状态机。

TCP状态机

其实网络上的传输并不是连接的，包括TCP。 TCP所谓的“连接”，其实只是在通信双方维持一种“连接状态”，使其看上去像是有连接一样。因此，TCP的状态转换非常重要。

下面是“TCP协议状态机”（图片来源）与“TCP链接创建”、“TCP链接断开”、“数据传输”的对比图。我将这两个图表并排放置，以便您可以轻松比较它们。手表。另外，下面两张图非常非常重要，一定要记住。

状态机为什么需要3次握手才能建立链接，4次挥手才能断开链接？

对于建立链路的三次握手来说，主要就是初始化Sequence Number的初始值。通信双方必须告知对方自己初始化的序列号（ISN：Initial Sequence Number）——，所以称为SYN，全称是Synchronize Sequence Numbers。就是上图中的x和y。这个数字应该作为以后数据通信的序列号，以保证应用层接收到的数据不会因为网络上的传输问题而出现乱序（TCP会使用这个序列号来拼接数据）。

对于4次挥手，实际上如果你仔细看的话，是2次，因为TCP是全双工的，所以发送方和接收方都需要Fin和Ack。不过一方是被动的，所以看起来就是所谓的4波。如果双方同时断开连接，就会进入CLOSING状态，然后到达TIME_WAIT状态。

关于建立连接时SYN超时。试想一下，如果服务器收到客户端发送的SYN并回复SYN-ACK，那么客户端就断开了，而服务器没有收到客户端的ACK，那么连接就处于中间状态，即，它既不成功也不失败。因此，如果服务器在一定时间内没有收到TCP，就会重新发送SYN-ACK。 Linux下，默认重试次数为5次，重试间隔从1s开始。 5次的重试间隔分别是1s、2s、4s、8s、16s，一共31s，第五次发送完之后，还要等32秒才知道第五次也超时了。因此，总共需要1s + 2s + 4s + 8s + 16s + 32s=2^6 -1=63s，TCP才会断开连接。

关于SYN Flood攻击。一些恶意者为此目的创建了SYN Flood 攻击——。向服务器发送SYN后，服务器就下线了。因此，服务器默认需要等待63s才断开连接。这样攻击者就可以连接服务器的SYN了。队列已满，无法处理正常的连接请求。因此Linux给出了一个叫tcp_syncookies的参数来处理这个问题。当SYN队列满时，TCP会创建一个特殊的Sequence Number，并通过源地址端口、目的地址端口和时间戳发回（也称为cookie）。如果是攻击者，则不会有任何反应。如果是正常连接，则会发回SYN Cookie，然后服务器就可以通过Cookie建立连接（即使你不在SYN队列中）。请注意，请不要使用tcp_syncookies 来处理正常的重负载连接。因为synccookies是TCP协议的妥协版本，并不严谨。对于正常请求，您应该调整三个TCP 参数供您选择。第一个是：tcp_synack_retries，可以用来减少重试次数；第二个是：tcp_max_syn_backlog，可以增加SYN连接数；第三个是：tcp_abort_on_overflow 如果无法处理，则简单地拒绝连接。

关于ISN的初始化。 ISN不能硬编码，否则会出现问题——。例如：如果连接建立后一直使用1作为ISN，如果客户端发送了30个报文段，但网络断开，那么客户端重新连接，又使用1。做ISN，但是之前连接的数据包到达，所以被视为新连接的数据包。这时候客户端的Sequence Number可能是3，服务器就认为客户端的Sequence Number是30。全乱了。 RFC793 表示ISN 将与假时钟绑定。这个时钟会每4微秒给ISN加1，直到超过2^32，再次从0开始。这样，一个ISN的周期约为4.55小时。因为我们假设我们的TCP Segment 在网络上的生存时间不会超过Maximum Segment Lifetime（缩写为MSL - 维基百科条目），所以只要MSL 的值小于4.55 小时，那么我们就不会重用该TCP Segment。 ISN。

关于MSL和TIME_WAIT。通过上面对ISN的描述，相信大家也知道MSL是怎么来的了。我们注意到，在TCP状态图中，从TIME_WAIT状态到CLOSED状态有一个超时设置。这个超时设置是2*MSL（RFC793定义MSL为2分钟，Linux设置为30s）。为什么会有TIME_WAIT？为什么不直接将其转移到CLOSED 状态呢？主要有两个原因： 1）TIME_WAIT确保peer有足够的时间接收ACK。如果被动关闭方没有收到Ack，就会触发被动端重发Fin，正好有2个MSL来来去去。 2）有足够的时间，这样这个连接就不会和后续的连接混在一起（你要知道有些自发起的路由器会缓存IP数据包，如果连接被重用，那么这些延迟的数据包可能会被接收到）与新连接混合）。您可以阅读这篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》

TIME_WAIT 数字太多。从上面的描述我们可以知道TIME_WAIT是一个非常重要的状态，但是如果有大并发的短链接，就会出现太多的TIME_WAIT，也会消耗大量的系统资源。只要你搜一下，你就会发现十个处理方法有九个教你设置两个参数，一个叫tcp_tw_reuse，另一个叫tcp_tw_recycle。这两个参数的默认值都是关闭的，后面的recycle比前面的resume更加激进，resume更加温和。另外，如果使用tcp_tw_reuse，必须设置tcp_timestamps=1，否则无效。这里，一定要注意，打开这两个参数会有一个很大的陷阱。 ——可能会导致TCP连接出现一些奇怪的问题（因为如上所述，如果不等待超时重用连接，新的连接可能无法建立起来。正如官方文档所说“不应该更改”没有技术专家的建议/请求”）。

关于tcp_tw_reuse。官方文档说tcp_tw_reuse加上tcp_timestamps（也叫PAWS，Protection Against Wrapped Sequence Numbers）可以从协议角度保证安全，但是需要两边都开启tcp_timestamps（可以阅读tcp_twsk_unique的源码）。我个人估计还是有一些场景会出现问题。

关于tcp_tw_recycle。如果tcp_tw_recycle开启，则会假设对端开启了tcp_timestamps，然后会比较时间戳。如果时间戳变大了，可以重复使用。然而，如果对端是NAT网络（例如：一家公司只使用一个IP用于公共网络）或者对端的IP被另一台设备复用，那么事情就会变得复杂。用于建立链接的SYN可能会直接丢失（可能会看到连接超时错误）（如果想观察Linux内核代码，请参考源代码tcp_timewait_state_process）。

关于tcp_max_tw_buckets。这是控制并发的TIME_WAIT数量。默认值为180000。如果超过限制，系统会销毁超出的部分，然后在日志中放置警告（如：时间等待桶表溢出）。官网文档说这个参数是用来对抗DDoS攻击的。也就说默认值180000不小了。这个还是需要根据实际情况来考虑。

数据传输中的序列号

下图是我访问coolshell.cn时从Wireshark截取的数据传输图，给大家展示一下SeqNum是如何变化的。（使用Wireshark 菜单中的统计- 流程图.）

SeqNum的变化可以看到SeqNum的增加与传输的字节数有关。上图中，三次握手后，来了两个Len:1440的包，第二个包的SeqNum变成了1441。那么返回的第一个ACK就是1441，说明第一个1440收到了。

TCP丢包时的重传机制：

TCP需要保证所有数据包都能到达，因此需要重传机制。

注意，接收端到发送端的Ack确认只会确认最后一个连续的数据包。比如发送端一共发送了5个数据1、2、3、4、5，接收端收到了1和2，所以回复了ack 3。然后收到了4（注意3是此时没有收到），此时TCP会做什么呢？我们需要知道，前面提到过，SeqNum和Ack都是基于字节数的，所以在ack时，不能跳转确认，只能确认连续收到的最大数据包，否则，发送方会认为之前的数据包已经被确认了。全部收到了。

重传原理超时重传机制

一种是不响应ack，等待3。当发送方发现没有收到3的ack并且超时时，就会重传3。接收方一旦收到3，就会回复4——，这意味着双方3、4已收到。

但是，这种方法会有一个严重的问题，就是因为要等待3，即使4和5都收到了，发送方也不知道发生了什么，因为没有收到Ack，所以，发送方可能会悲观地认为已经丢失了，所以也可能导致4和5的重传。

有两种选择：

一种是仅重传超时数据包。这是第三条数据。

另一种是超时后重传所有数据，即第3、4、5个数据。

这两种方法各有优点和缺点。第一个可以节省带宽，但速度很慢。第二种会更快，但会浪费带宽并可能导致无用功。但总体来说不好。因为都是在等待超时，超时可能会很长（下一篇我会讲TCP如何动态计算超时）

快速重传机制

因此，TCP引入了一种称为快速重传的算法，该算法不是由时间驱动，而是由数据驱动进行重传。也就是说，如果数据包没有连续到达，则将确认最后一个可能丢失的数据包。如果发送方连续3次收到相同的ack，就会重传。快速重传的优点是不需要等待超时才重传。

例如：如果发送方发送了1、2、3、4、5个数据，则第一个数据先到达，因此返回2个数据。但是由于某种原因没有收到2，而3到了，所以发回ack。 2、下面的4和5已经到达，但是ack 2还是发回来了，因为2还没有收到，所以发送方收到了3个ack=2的确认，知道2还没有到达，所以立即重定向2。然后，接收端收到2。此时因为3、4、5都收到了，所以ack返回6。示意图如下：

图像

快速重传只解决一个问题，就是超时问题。它仍然面临着一个艰难的选择，即是重传上一篇还是重传所有问题。对于上面的例子，我们应该重传#2还是重传#2、#3、#4、#5呢？因为发送方不知道这三个连续的ack(2)是谁发送的？也许发送端发送了20条数据，分别来自#6、#10、#20。这样，发送方很可能会重传这堆数据从2到20（这就是一些TCP的实际实现）。可见，这是一把双刃剑。

塞克法

另一种更好的方法称为：选择性确认(SACK)（请参阅RFC 2018）。此方法需要在TCP 标头中添加SACK。 ACK仍然是Fast Retransmit的ACK，SACK报告收到的分片数据。见下图：

图像

这样发送端就可以根据返回的SACK知道哪些数据已经到达，哪些数据未到达。因此对快速重传算法进行了优化。当然，这个协议需要双方的支持。 Linux下可以通过tcp_sack参数开启该功能（Linux 2.4后默认开启）。

这里还有一个问题需要注意：——接收器Reneging。所谓Reneging是指接收方有权丢失已经向发送方报告的SACK中的数据。不鼓励这样做，因为这会使问题复杂化。然而，当接收者这样做时可能会出现一些极端情况，例如将内存留给其他更重要的事情。因此，发送方不能完全依赖SACK。仍然要依赖ACK并维持Time-Out。如果后续的ACK没有增加，仍然要重传SACK。另外，接收端永远不能发送SACK数据包。标记为确认。

注意：SACK会消耗发送方的资源。试想一下，如果攻击者向数据发送方发送一堆SACK选项，这将导致发送方开始重传甚至遍历已经发送的数据，这会消耗发送方的大量资源。详情请参阅《TCP SACK的性能权衡》

Duplicate SACK 收到重复数据的问题

Duplicate SACK又称为D-SACK，主要是利用SACK来告诉发送方哪些数据被重复接收。详细描述和示例可以在RFC-2883 中找到。以下是一些示例（来自RFC-2883）

D-SACK使用SACK的第一段作为标志。

如果SACK第一段的范围被ACK覆盖，则为D-SACK

如果SACK的第一段的范围被SACK的第二段覆盖，则为D-SACK

示例1：ACK丢包

下面的例子中，有两个ACK丢失，所以发送端重传了第一个数据包（3000-3499），所以接收端发现重复收到了，于是回复了SACK=3000-3500，因为ACKs were all 到达4000意味着4000之前的数据都已经收到了，所以这个SACK就是D-SACK——，它的目的是告诉发送方我收到了重复的数据，而我们的发送方也知道数据包没有丢失，但ACK 数据包丢失。

示例2、网络延迟

在下面的例子中，网络数据包（1000-1499）被网络延迟，导致发送方没有收到ACK，而后续到达的三个数据包触发了“快速重传算法”，因此被重传，但是重传时，延迟的数据包又到达了，所以返回了一个SACK=1000-1500。因为ACK已经达到3000，所以这个SACK是D-SACK——，表明已经接收到重复的数据包。

在这种情况下，发送方知道“快速重传算法”触发的重传不是因为传出数据包丢失，也不是因为响应ACK数据包丢失，而是因为网络延迟。

可见，D-SACK的引入有几个好处：

了解这些事情可以帮助TCP很好的了解网络情况，从而更好的控制网络上的流量。

好了，文章到此结束，希望可以帮助到大家。