实际应用中，TCP/IP协议栈是如何工作的？

Posted 2021-04-25 车小胖谈网络

斜体部分为读者提问

TCP/IP协议栈中各个协议的作用及其结构，题主已经学懂了。但是对于实际应用中，各个协议如何协同工作的，还是有些不理解，希望大佬们能赐教：

1、以浏览器请求一张大图片为例，说下按我的理解吧：先三次TCP握手（NO1 NO2 NO3），然后发出一个http请求（NO4），服务端向客户端确认收到了请求（NO5）,服务端开始发送图片，实际上是一个http响应，但是因为该响应消息很大（图片很大），所以该http响应消息被TCP分段（由TCP协议栈进程进行分段，浏览器不作处理）然后再发送（NO6~NO81，其中有服务端发送的分段，也有客户端的确认），客户端收到所有分段后，重组为一个http响应报文，交付给浏览器，浏览器确认并断开连接（NO83 NO84），以上理解是否有误？

2、关于wireshark的疑惑：网上好多文章说wireshark是针对网卡，抓取传输层的包，这种说法是否正确？

我在使用wireshark的时候发现，对于ping，没有传输层流量，只有网络层icmp分组消息，也可以被wireshark捕捉并显示为icmp包的啊，并不支持这种说法；对于比较小的http消息，其在软件中显示就是一条，但可以对应查看到TCP头部、IP头部，支持这种说法；对于较大的http消息，被切割成了多个tcp分段，所以会显示成多个tcp条目，只有最后一条因为包含http头部，所以显示为http（NO82），也是支持这种说法的。

为了方便阅览，去掉了一些时间源目IP列，高端口是本地浏览器，80是目标服务器。

该环境使用了openvpn，监听的是openvpn的虚拟网卡，所以包内容看起来有些不一样。。。特此说明下。

问题一：对TCP的理解基本上是对的，但是有一个地方是不准确的。

TCP不会对接收到的segments，拼接成一个文件再让应用程序取走，这是不对的！

第一：如果这么做，一个大文件很容易就将接收方的接收缓存耗尽，压根没有办法再接收后续数据。

第二：TCP根本不理解segment里是什么内容，在这个问题里，它们只是1397字节的segment，至于谁是第一个segment、谁是第二个，TCP是知道的，TCP可以将segment按序排队放入接收缓存，等待应用程序取走（异步操作），这是TCP唯一能做的！

TCP不会做拼接http报文的工作(因为压根不懂)，TCP只保证将接收到字节流按序提交给浏览器就可以了。

这里的客户端应用程序为浏览器，浏览器读取了segment 1、2、3....，浏览器通过第一个segment就明白接下来传输的是一个多少字节长的文件。浏览器根据文件的长度，从文件的起点一直拼接到长度指示的终点。当文件完整得到了，浏览器就在页面上呈现给用户。

问题二：wireshark内部如何实现，除了核心开发人员，没有人可以知道细节。

抓包软件大同小异，如果把抓包软件比作捞鱼的渔网，这个渔网能捞多少鱼，完全取决于是在TCP/IP协议栈捞鱼，还是在网卡上捞鱼。为了更好说明这个问题，做一个实验：

实验：Ping 127.0.0.1

之所以做这个实验，是想证明一点，主机与自己通信，直接在TCP/IP协议栈里完成，而无需数据链路层的参与。以下是整个实验过程：

分别使用windows 自带的ping ，以及第三方的nping，分别ping 127.0.0.1，这个127.0.0.1就是windows主机自己的loopback IP，只用于主机内部进程间通信。

 

抓包显示，数据链路层是空的，所以可以推测，主机内部进程之间通信，并不需要经过物理网卡。

为了证明Ping报文没有经过物理网卡，在物理网卡上抓包，结果没有抓到这些Ping包。

有同学会说，127.0.0.1是一个软件环回接口，没有硬件MAC，所以Ping报文才不会有硬件网卡的参与。

 

本机的网卡绑定的IP = 10.1.4.2，Ping 10.1.4.2 一探究竟。

同样，也没有以太网协议头，自然就没有 Source / Destination MAC。

为了证明Ping报文没有经过物理网卡，在物理网卡上抓包，结果也没有抓到这些Ping包。

通过这个实验，可以得到这样的结论：

操作系统的协议栈，当发现IP报文的Destination IP ==主机任何接口IP时，不管是127.0.0.1，还是这里的10.1.4.2，一律环回(loopback) 处理。

将需要做loopback的报文，直接从IP协议栈的发送缓冲区copy到接收缓冲区，造成的结果就是，这些IP报文仿佛是从硬件网卡接收到的一样。

由于IP报文在IP协议栈(三层)已经掉头向上走，而不会向下走，所在在硬件网卡上是捕获不到的。

抓到127.0.0.1的ping包，是因为wireshark捕获接口是软件环回接口适配器，工作在TCP/IP协议栈(三层及以上)内，所以能够把TCP/IP协议栈内流动的流量复制下来，自然wireshark能够捕获到。

而当wireshark捕获接口是硬件网卡适配器，工作在硬件网卡(二层)内，而ping1227.0.0.1的流量不会下放到基层(二层)，网卡自然看不到这些流量，所以wireshark不会捕获到。

Wireshark工作层面

或工作在二层，或工作在三层，这完全取决于wireshark用户选择捕获什么样的网络适配器，这些上文已经说了很多。

Wiresharke工作原理

让网卡或协议栈对于进出(Incoming / Outgoing)的流量做一个复制，wireshark把复制好的数据，按照时间先后次序和协议格式，显示成用户友好的界面，供用户做协议分析。

Wireshark可靠性

这个问题另外一个说法是，wireshark是100%可靠的吗？

答案是否定的，Wireshark的可靠性依赖于硬件网卡或IP协议栈，而这些底层实现并不能完全100%可靠，所以wireshark并不能100%保证一个不漏的捕获所有的报文。

对于wireshark捕获到的报文，那意味着网络上确实产生过那个报文。

但在极端情况下，wireshark是有可能漏掉一些报文的，尽管概率是极低的。

通俗地说，有证明确实是有，没有并不能证明是没有！

对于一切网络工具，需要借助它们强大的功能，但是不要100%迷信它们。在网络排错时，要用怀疑的眼光审视一切，才能找出隐藏很深的root  cause。

留给读者一个问题，只要长期阅读作者文章的朋友肯定可以回答得出。

问题：Wireshark可以捕获到CRC Error的以太网报文吗？

如果读者知道答案，可以在评论区一起讨论，谢谢！

有一次经过上海人民广场公园，见识了赫赫有名的相亲角，看到很多头发花白的家长手拿一张纸牌，上面有自己成年孩子的概况，有的还附有生活照，或高大帅气、或甜美可人。很多男生、女生很优秀，可能限于接触范围，一直藏于深闺无人识。。。

如果读者朋友们喜欢这位姑娘，请多几次红娘，转发给您身边的朋友阅读，让更多的读者发现这位羞答答的姑娘。

赠人玫瑰，手留余香。。。