《网络是怎样连接的》读书笔记1

《网络是怎样连接的》读书笔记

1. 写在前面

今日看到一篇博文，作者说”写成博客的目的是防止自己走马观花，花了一堆时间还什么搜没学到“，我自诩接受、学习新事物比较快，然而在实际学习的过程中不是进度缓慢就是过于走马观花、雁过无痕。因此在这段时间希望能以写成体系的博客来督促、约束自己的学习，期望能够真正的获取一些知识。

对于读书笔记应该记什么，我也在探索中、之前读的几本书都是用思维导图的方式整理出来、但是个人感觉效果甚微。这些读书笔记也是我的一个尝试，文字、知识、逻辑方面可能都有不足之处，慢慢改进。我的文章如果能给大家带来知识和方便、那自然是最好不过。我希望大家如果对这些书籍这些知识感兴趣，最好去亲自读一下原书，很多书看起来不薄，但跟着作者引导、再结合自身需要，两三天都可以读完。好了，我也不多说了，接下来是正文。

2、关于这本书

《网络是怎样连接的》第2版，是日本作家户根勤于著作、周自恒翻译的一本通俗易懂、图文并茂的讲述计算机网络的书籍。

关于这本书的赞誉、我在这里就不赘述了。我谈谈我个人对这本书的感受以及我对计算机网络知识体系的认识。

我主要的计算机网络知识是在学校的计算机网络课程中学到的，学校里才用的教材是谢希仁老师的《计算机网络》第七版，这本书的讲解方向是从底层向上层，采用的是“物理层、数据链路层、网络（际）层、运输层、应用层”五层模型，因此我的计算机网络知识框架也是在这个基础上建立起来的。还有一本《计算机网络自顶向下方法》口碑很不错，只不过篇幅过大，我还没有读完，以后有时间也会写它的读书笔记。说回正题这次这本《网络是怎样连接的》和上述两本书的讲述路线都不相同、它从浏览器出发，向下到协议栈（主要是TCP和IP）、网卡，再到集线器、交换机、路由器，随后是接入网、缓存服务器，最后到达Web服务器。这样的讲述路线非常清晰、直观、易于接受。不过由于原书是07年成书，加之其中有些内容很多时候是一种循序渐进的方式讲解的，（当然，不是说它不好，而是对于友好。）里面有些知识会于我已经建立起来的知识体系不适应，这也让我重组了我的知识框架。

在我的认识里，计算机网络是一个分层的、像两个对着的楼梯一样的体系。下层为上层提供服务、假设我是IP层的一名“员工”，我只知道有人会告诉我要将要送东西A，我只负责根据IP将A送过去、而对我来说、送过去指的就是把A加上头部、找到一个出口、扔出去，自然就会有人把它送过去；有些时候我也会从“下属”那里拿上来东西，检查一下包装是不是我的，如果是就把它交给上级。当然我这个例子应该是有一些bug的。

今天的主角还是《网络是怎样连接的》，这本书给我带来的收获有主要有两点：

从浏览器到Web服务器的一条精彩且详细的“探险之旅”。
让我对已有的计算机网络知识进行思考和完善。

额，说了这么些，我都快被自己绕晕过去了，最后总结一下：

这本《网络是怎样连接的》非常适合入门、可以说是计算机网络最好的领路人。
如果已有计算机网络的知识基础、可以按着这条怎样连接的路走一下，或许会另有发现。

放一张图

3. 第一章Web浏览器

终于把前面那部分说完了，接下来就是书里面的内容了。

“我们的探索之旅是从在浏览器中输入网址（URL）开始的。”，例如输入http://www.lab.glasscom.com/sample1.html，浏览器就会生成请求信息“请给我sample1. html这一文件中储存的网页数据”。

浏览器的具体工作步骤是：

解析URL
生成HTTP请求消息
向DNS服务器查询域名对应的ip地址
委托操作系统内部的协议栈将消息发送给Web服务器，按照指定的顺序来调用Socket库中的程序组件。

在第三步中，我们输入的是域名、而连接所需要的的是ip地址，因此我们需要进行“域名解析”：向DNS服务器“询问”域名对应的ip地址。

对于DNS服务器，我们的计算机上一定有相应的DNS客户端，而相当于DNS客户端的部分称为DNS解析器，或者简称解析器。解析器实际上是一段程序，它包含在操作系统的Socket库中。浏览器调用Socket库中的解析器。

以http://www.lab.glasscom.com/为例，相当于一个层级的部分称为域。com域的下一层是glasscom域，再下一层是lab域，再下面才是www这个名字。

一个域的信息是作为一个整体存放在DNS服务器中的，不能将一个域拆开来存放在多台DNS服务器中，而一台DNS服务器中也可以存放多个域的信息。将负责管理下级域的DNS服务器的IP地址注册到它们的上级DNS服务器中，然后上级DNS服务器的IP地址再注册到更上一级的DNS服务器中。

因此查询的时候先询问最近的域名服务器A“访问这个域名服务器也需要知道它的ip地址，这个ip地址我们已知”如果A知道（“DNS服务器会从域名与IP地址的对照表中查找相应的记录，并返回IP地址。" 在计算机网络中有很多”表“ 路由器有交换机有）则返回ip地址的值，如果A不知道则会向根域名服务器查找、依次轮询查找直到找到对应的ip地址。

此外，有时候并不需要从最上级的根域开始查找，因为DNS服务器有一个缓存功能，可以记住之前查询过的域名。（缓存也是老朋友呀）.

第四步委托协议栈发送信息，“知道了IP地址之后，就可以委托操作系统内部的协议栈向这个目标IP地址，也就是我们要访问的Web服务器发送消息了”，各种使用网络的应用程序都是需要委托协议栈来收发信息（包括刚刚提到的解析器）

向操作系统内部的协议栈发出委托时，需要按照指定的顺序来调用Socket库中的程序组件。对于浏览器来说，协议栈为自己建立了一条“通路”只要在通路建立好之后把信息放入到通路中就可以了。

收发数据的操作分为若干个阶段，可以大致总结为以下4个。这4个操作都是由操作系统中的协议栈来执行的。

创建套接字（创建套接字阶段）
将管道连接到服务器端的套接字上（连接阶段）
收发数据（通信阶段）
断开管道并删除套接字（断开阶段）

创建套接字的具体过程会在下一章讲解，这里关于套接字、描述符我一直有很大的疑惑、希望到时候可以说清。

几个概念：

应用程序是通过“描述符”这一类似号码牌的东西来识别套接字的。

描述符：应用程序用来识别套接字的机制

IP地址和端口号：客户端和服务器之间用来识别对方套接字的机制

第一章到这里就结束了，我并没有把地址张的内容和盘托出、只是挑选了对我来说有帮助的知识。

4. 第二章协议栈、网卡

第二章会具体讲解第一章中提到的“创建套接字（创建套接字阶段）、将管道连接到服务器端的套接字上（连接阶段）、收发数据（通信阶段）断开管道并删除套接字（断开阶段）“这四个阶段。

注意这里所讲的知识已经是TCP UDP IP以及更下层的协议的知识了

4.1创建套接字

协议栈的内部

在互联网上传送数据时，数据会被切分成一个一个的网络包[插图]，而将网络包发送给通信对象的操作就是由IP来负责的。

套接字是啥？

在协议栈内部有一块用于存放控制信息的内存空间，这里记录了用于控制通信操作的控制信息，例如通信对象的IP地址、端口号、通信操作的进行状态等。我们可以说这些控制信息就是套接字的实体，或者说存放控制信息的内存空间就是套接字的实体。

协议栈是根据套接字中记录的控制信息来工作的。

创建套接字

创建套接字时，首先分配一个套接字所需的内存空间，然后向其中写入初始状态。

将表示这个套接字的描述符告知应用程序。描述符相当于用来区分协议栈中的多个套接字的号码牌。

收到描述符之后，应用程序在向协议栈进行收发数据委托时就需要提供这个描述符。由于套接字中记录了通信双方的信息以及通信处于怎样的状态，所以只要通过描述符确定了相应的套接字，协议栈就能够获取所有的相关信息，这样一来，应用程序就不需要每次都告诉协议栈应该和谁进行通信了。（是不是可以这样认为，描述符是某一个套接字的名字应用程序在委托协议栈进行收发数据时，告诉协议栈我的链接是那个套接字，协议栈不关心是哪个应用程序，它只认套接字。）

4.2连接服务器

应用程序（浏览器）就会调用connect，随后协议栈会将本地的套接字与服务器的套接字进行连接。

套接字刚刚创建完成的时候，里面并没有存放任何数据，也不知道通信的对象是谁。“浏览器可以根据网址来查询服务器的IP地址，而且根据规则也知道应该使用80号端口，但只有浏览器知道这些必要的信息是不够的，因为在调用socket创建套接字时，这些信息并没有传递给协议栈。因此，我们需要把服务器的IP地址和端口号等信息告知协议栈，这是连接操作的目的之一。”（以上是客户端浏览器的情况）。

服务器上也会创建套接字（具体在第六章介绍），我们需要让客户端向服务器告知必要的信息，比如“我想和你开始通信，我的IP地址是xxx.xxx. xxx.xxx，端口号是yyyy。”可见，客户端向服务器传达开始通信的请求，也是连接操作的目的之一。（这就是一种交换控制信息）

此外，当执行数据收发操作时，我们还需要一块用来临时存放要收发的数据的内存空间，这块内存空间称为缓冲区，它也是在连接操作的过程中分配的。

以上三点就是**“连接”**这个词代表的具体含义。

控制信息有哪些？

第一类是客户端和服务器相互联络时交换的控制信息。这些信息不仅连接时需要，包括数据收发和断开连接操作在内，整个通信过程中都需要，这些内容在TCP协议的规格中进行了定义。（TCP头部 IP头部 MAC头部）
控制信息还有另外一类，那就是保存在套接字中，用来控制协议栈操作的信息[插图]。应用程序传递来的信息以及从通信对象接收到的信息都会保存在这里，还有收发数据操作的执行状态等信息也会保存在这里，协议栈会根据这些信息来执行每一步的操作。

操作系统不同、协议栈的实现不同，因此我们无法具体说明协议栈里到底保存了哪些控制信息，但可以用命令来显示一些重要的套接字控制信息，这些信息无论何种操作系统的协议栈都是共通的。（规则相同隐藏差异）

连接操作的实际过程

connect(<描述符>,<服务器IP地址和端口号,……>)

上面的调用提供了服务器的IP地址和端口号，这些信息会传递给协议栈中的TCP模块。然后，TCP模块会与该IP地址对应的对象，也就是与服务器的TCP模块交换控制信息。这一交互过程包括下面几个步骤：

连接操作的第一步是在TCP模块处创建表示连接控制信息的头部。通过TCP头部中的发送方和接收方端口号可以找到要连接的套接字。
TCP模块会将信息传递给IP模块并委托它进行发送（第一次握手）
服务器的TCP模块根据TCP头部中的信息找到端口号对应的套接字，套接字中会写入相应的信息，并将状态改为正在连接。服务器TCP模块会将TCP头部传递给IP模块，并委托IP模块向客户端返回响应。（第二次握手）
客户端收到网络包，得知SYN为1 连接成功，这时会向套接字中写入服务器的IP地址、端口号等信息，同时还会将状态改为连接完毕。（在第二次握手后）客户端也需要将ACK比特设置为1并发回服务器，告诉服务器刚才的响应包已经收到。当这个服务器收到这个返回包之后，连接操作才算全部完成。（第三次握手）

现在，连接已经连接了，套接字就已经进入随时可以收发数据的状态了，大家可以认为这时有一根管子把两个套接字连接了起来。

4.3收发数据

协议栈并不关心应用程序传来的数据是什么内容。应用程序在调用write时会指定发送数据的长度，在协议栈看来，要发送的数据就是一定长度的二进制字节序列而已。（这也是分层计算机网络中重要的特征）

协议栈并不是一收到数据就马上发送出去，而是会将数据存放在内部的发送缓冲区中，并等待应用程序的下一段数据。

积累多少数据才能发送的判断要素：

每个网络包能容纳的数据长度
1. MTU：一个网络包的最大长度，以太网中一般为1500字节。
2. MSS：除去头部之后，一个网络包所能容纳的TCP数据的最大长度。
时间

两个要素相互矛盾，二者的平衡实际如何判断是由协议栈的开发者来决定的。应用程序在发送数据时可以指定一些选项。

对较大的数据进行拆分

使用ACK号确认网络包已收到

在实际的通信中，序号并不是从1开始的，而是需要用随机数计算出一个初始值，这是因为如果序号都从1开始，通信过程就会非常容易预测，有人会利用这一点来发动攻击。在将SYN设为1的同时，还需要同时设置序号字段的值，而这里的值就代表序号的初始值。

通信是双向的，客户端和服务器双方都需要各自计算序号。

TCP通过“序号”和“ACK号”可以确认接收方是否收到了网络包。在得到对方确认之前，发送过的包都会保存在发送缓冲区中。如果对方没有返回某些包对应的ACK号，那么就重新发送这些包。可靠交付

根据网络包平均往返时间调整ACK号等待时间

使用窗口有效管理ACK号

接收方需要告诉发送方自己最多能接收多少数据，然后发送方根据这个值对数据发送操作进行控制，这就是滑动窗口方式的基本思路。

ACK与窗口的合并

这里以一方向另一方通信为例

更新窗口大小的时机应该是接收方从缓冲区中取出数据传递给应用程序的时候。当接收方将数据传递给应用程序，导致接收缓冲区剩余容量增加时，就需要告知发送方，这就是更新窗口大小的时机。接收方在发送ACK号和窗口更新时，并不会马上把包发送出去，而是会等待一段时间，在这个过程中很有可能会出现其他的通知操作，这样就可以把两种通知合并在一个包里面发送了。因此只要发送最后一个ACK号就可以了。

接收HTTP响应消息

协议栈会检查收到的数据块和TCP头部的内容，判断是否有数据丢失，如果没有问题则返回ACK号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。（这里是协议栈）

上面那里都是协议栈的工作，这里再来看看浏览器（应用程序）

浏览器在委托协议栈发送请求消息之后，会调用read程序来获取响应消息。

4.4从服务器断开并删除套接字

收发数据结束的时间点应该是应用程序判断所有数据都已经发送完毕的时候。Web为例，在HTTP1.0中浏览器向Web服务器发送请求消息，Web服务器再返回响应消息，这时收发数据的过程就全部结束了，服务器一方会发起断开过程。而HTTP1.1中服务器返回响应信息后，还会客户端还会发起下一个请求，知道客户端没有请求、客户端一方会发起断开过程（持久连接）（“减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面的显示速度也就相应提高了。”《图解HTTP》）

协议栈在设计上允许任何一方先发起断开过程。这里我们以服务器一方发起断开过程为例来进行讲解。四次挥手

首先，服务器一方的应用程序会调用Socket库的close程序。然后，服务器的协议栈会生成包含断开信息的TCP头部，具体来说就是将控制位中的FIN比特设为1。
当收到服务器发来的FIN为1的TCP头部时，客户端的协议栈会将自己的套接字标记为进入断开操作状态。然后，为了告知服务器已收到FIN为1的包，客户端会向服务器返回一个ACK号。（过了一会儿，应用程序就会调用read来读取数据[插图]。这时，协议栈不会向应用程序传递数据[插图]，而是会告知应用程序（浏览器）来自服务器的数据已经全部收到了。）
客户端应用程序会调用close来结束数据收发操作，这时客户端的协议栈也会和服务器一样，生成一个FIN比特为1的TCP包，然后委托IP模块发送给服务器。
一段时间之后，服务器就会返回ACK号。

套接字并不会立即被删除，而是会等待一段时间之后再被删除。防止重传的FIN影响下一个连接。

总结：

4.5IP与以太网的包收发操作

（以上是TCP的主场，现在轮到IP啦）

网络包是啥？

包是由头部和数据两部分构成的。头部包含目的地址等控制信息，头部后面就是委托方要发送给对方的数据

（a）MAC头部（用于以太网协议）

（b）IP头部（用于IP协议）

包收发操作的起点是TCP模块委托IP模块发送包的操作.

IP模块负责添加如下两个头部。

MAC头部：以太网用的头部，包含MAC地址
IP头部：IP用的头部，包含IP地址

接下来，封装好的包会被交给网络硬件（这个硬件成为网卡），例如以太网、无线局域网等

包送达对方之后，对方会作出响应。返回的包也会通过转发设备发送回来，然后我们需要接收这个包。接下来，IP模块会将MAC头部和IP头部后面的内容，也就是TCP头部加上数据块，传递给TCP模块。接下来的操作就是我们之前讲过的TCP模块负责的部分了。

无论要收发的包是控制包还是数据包，IP对各种类型的包的收发操作都是相同的。（这和上面协议栈不关心应用程序传下来的数据是啥一样）

（关于IP这块儿内容其实我个人感觉是比较乱、也可能使我没有理清思路把）

IP模块的具体工作过程

生成包含接收方IP地址的IP头部

IP模块接受TCP模块的委托负责包的收发工作，它会生成IP头部并附加在TCP头部前面。这个地址是由TCP模块告知的，而TCP又是在执行连接操作时从应用程序那里获得这个地址的。另外，发送方IP地址（对于发送方这是自己的IP）需要判断发送所使用的网卡，并填写该网卡的IP地址。

生成以太网用的MAC头部

IP头部中的接收方IP地址表示网络包的目的地，通过这个地址我们就可以判断要将包发到哪里，但在以太网的世界中，TCP/IP的这个思路是行不通的。因此，IP模块在生成IP头部之后，会在它前面再加上MAC头部。MAC头部是以太网使用的头部，它包含了接收方和发送方的MAC地址等信息。

IP模块根据路由表Gateway栏的内容判断应该把包发送给谁。

（现在的问题是，对方的MAC地址是啥？）

ARP 地址解析协议

在以太网中，有一种叫作广播的方法，可以把包发给连接在同一以太网中的所有设备。ARP就是利用广播对所有设备提问：“××这个IP地址是谁的？请把你的MAC地址告诉我。”然后就会有人回答：“这个IP地址是我的，我的MAC地址是××××。”（这是在缓存中找不到的情况）

实际上，我们会将查询结果放到一块叫作ARP缓存（老朋友）的内存空间中留着以后用。也就是说，在发送包时，先查询一下ARP缓存，如果其中已经保存了对方的MAC地址，就不需要发送ARP查询，直接使用ARP缓存中的地址。

当IP地址发生变化时，ARP缓存的内容就会和现实发生差异，为了防止这种问题的发生，ARP缓存中的值在经过一段时间后会被删除，一般这个时间在几分钟左右。（只要是缓存都会有这样的问题，各有各的解决方案）

以太网

以太网是一种为多台计算机能够彼此自由和廉价（成本低）地相互通信而设计的通信技术。这种网络的本质其实就是一根网线。图上还有一种叫作收发器的小设备，它的功能只是将不同网线之间的信号连接起来而已。

当一台计算机发送信号时，信号就会通过网线流过整个网络，最终到达所有的设备。在信号的开头加上接收者的信息，也就是地址（MAC地址）。与接收者地址匹配的设备就接收这个包，其他的设备则丢弃这个包，这样我们的包就送到指定的目的地了。

中继式集线器 本质不变

交换式集线器 信号只会流到根据MAC地址指定的设备，而不会到达其他设备了。当然，根据MAC地址来传输包这一点并没有变，因此MAC头部的设计也得以保留。

具备这3个性质的网络就是以太网

将包发送到MAC头部的接收方MAC地址代表的目的地
用发送方MAC地址识别发送方
用以太类型识别包的内容

以太网和IP一样，并不关心网络包的实际内容，因此以太网的收发操作也和TCP的工作阶段无关，都是共通的。

网卡

网卡也无法单独工作，要控制网卡还需要网卡驱动程序。网卡驱动程序也是厂商开发的专用程序。

**网卡的ROM中保存着全世界唯一的MAC地址，这是在生产网卡时写入的。**网卡中保存的MAC地址会由网卡驱动程序读取并分配给MAC模块。

给网络包再加3个控制数据

网卡驱动从IP模块获取包之后，会将其复制到网卡内的缓冲区中，然后向MAC模块发送发送包的命令。
MAC模块会将包从缓冲区中取出，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。（报头是一串像10101010…这样1和0交替出现的比特序列，长度为56比特，它的作用是确定包的读取时机，末尾的FCS（帧校验序列）用来检查包传输过程中因噪声导致的波形紊乱、数据错误，它是一串32比特的序列，是通过一个公式对包中从头到尾的所有内容进行计算而得出来的。）

怎么以电信号的形式发送？

用电信号来表达数字信息时，我们需要让0和1两种比特分别对应特定的电压和电流这样的电信号就可以表达数字信息。并且接收时通过测量信号中的电压和电流变化，还原出0和1两种比特的值。实际的信号并不像图所示的那样有分隔每个比特的辅助线，因此在测量电压和电流时必须先判断出每个比特的界限在哪里。

时钟信号

将数据信号和时钟信号叠加在一起。

由于时钟信号是像图（b）这样按固定频率进行变化的，只要能够找到这个变化的周期，就可以从接收到的信号（c）中提取出时钟信号（b），进而通过接收信号（c）和时钟信号（b）计算出数据信号（a）

重点在于如何判断时钟信号的变化周期。我们不能一开始就发送包的数据，而是要在前面加上一段用来测量时钟信号的特殊信号，这就是报头的作用。

发送信号的操作分为两种：

一种是使用集线器的半双工模式。
另一种是使用交换机的全双工模式。

在半双工模式中，为了避免信号碰撞，需要碰撞检测。

（这里对网卡中的各个模块间的任务职责进行细分讲解）

网卡的MAC模块生成通用信号，然后由PHY（MAU）模块转换成可在网线中传输的格式，并通过网线发送出去。PHY（MAU）的职责并不是仅仅是将MAC模块传递过来的信号通过网线发送出去，它还需要监控接收线路中有没有信号进来。在开始发送信号之前，需要先确认没有其他信号进来，这时才能开始发送。

（关于碰撞监测，这不再细说）

接收返回包

从包开头到结尾的所有比特套用到公式中计算出FCS，然后和包末尾的FCS进行对比。
如果FCS校验没有问题，接下来就要看一下MAC头部中接收方MAC地址与网卡在初始化时分配给自己的MAC地址是否一致，以判断这个包是不是发给自己的。如果接收方MAC地址和自己MAC地址一致，则将包放入缓冲区中。
网卡会通知计算机收到了一个包（中断），网卡向扩展总线中的中断信号线发送信号，该信号线通过计算机中的中断控制器连接到CPU。CPU会暂时挂起正在处理的任务，切换到操作系统中的中断处理程序。然后，中断处理程序会调用网卡驱动，控制网卡执行相应的接收操作。

将服务器的响应包从IP传递给TCP

（这里是协议栈的工作）

服务器返回的包的以太类型应该是0800，因此网卡驱动会将其交给TCP/IP协议栈来进行处理。

检查IP头部，确认格式是否正确
查看接收方IP地址，如果接收方IP地址不是自己的地址，那一定是发生了什么错误。客户端计算机不负责对包进行转发，因此不应该收到不是发给自己的包（当然，如果是服务器，也会进行转发）。当发生这样的错误时，IP模块会通过ICMP消息将错误告知发送方。
如果接收到的包是经过分片的，那么IP模块会将它们还原成原始的包。
交给TCP模块
TCP模块会根据IP头部中的接收方和发送方IP地址，以及TCP头部中的接收方和发送方端口号来查找对应的套接字。根据套接字中记录的通信状态，执行相应的操作了。

（严格来说，TCP 模块和 IP 模块有各自的责任范围，TCP 头部属于 TCP 的责任范围，而 IP头部属于 IP 模块的责任范围。根据这样的逻辑，当包交给 TCP 模块之后，TCP 模块需要查询 IP头部中的接收方和发送方 IP 地址来查找相应的套接字，这个过程就显得有点奇怪。因为 IP 头部是 IP 模块负责的，TCP 模块去查询它等于是越权了。如果要避免越权，应该对两者进行明确的划分，IP 模块只向 TCP 模块传递 TCP 头部以及它后面的数据，而对于 IP 头部中的重要信息，即接收方和发送方的 IP 地址，则由 IP 模块以附加参数的形式告知 TCP 模块。然而，如果根据这种严格的划分来开发程序的话，IP 模块和 TCP 模块之间的交互过程必然会产生成本，而且 IP 模块和 TCP 模块进行类似交互的场景其实非常多，总体的交互成本就会很高，程序的运行效率就会下降。因此，就像之前提过的一样，不妨将责任范围划分得宽松一些，将 TCP 和IP 作为一个整体来看待，这样可以带来更大的灵活性。
此外，关于为什么查找套接字同时需要接收方和发送方的 IP 地址和端口号，我们会在第 6 章介绍端口号机制时一起讲解。）

总结：为什么我在第一次看这里会觉得比较乱呢，因为这里原书2.5（文章中4.4）的内容包含信息量过大，IP层、数据链路层、物理层，还介绍了如何转换成光信号和中断。不过，日过能跟着作者的思路走，这部分的知识并不算复杂。文章中一直强调的协议栈，主要指的是TCP/IP协议栈，第二章将的是协议栈、可以看出TCP/IP确实是占据主要地位的，文中将其他协议都随着TCP和IP的工作过程都涉及到啦，如果早点理解这个，或许这部分会看得轻松一点。下次再看这部分时，不妨将已有的分层知识暂时“忘掉“，只跟着作者的思路走，或许效果会好。

4.6UDP协议的收发操作

向DNS服务器查询IP地址的时候我们用的也是UDP协议。

在某种情况下，即便没有TCP这样复杂的机制，我们也能够高效地重发数据，这种情况就是数据很短，用一个包就能装得下。如果只有一个包，就不用考虑哪个包未送达了，因为全部重发也只不过是重发一个包而已，这种情况下我们就不需要TCP这样复杂的机制了。此外，此外，我们发送了数据，对方一般都会给出回复，只要将回复的数据当作接收确认就行了，也不需要专门的接收确认包了。

UDP 可发送的数据最大长度为 IP 包的最大长度减去 IP 头部和 UDP 头部的长度。

收发数据之前也不需要交换控制信息，也就是说不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上UDP头部，然后交给IP进行发送就可以了。UDP只负责单纯地发送包而已。

音视频一般采用UDP，但也可以不采用。

音频和视频数据必须在规定的时间内送达，一旦送达晚了，就会错过播放时机，导致声音和图像卡顿。如果像TCP一样通过接收确认响应来检查错误并重发，重发的过程需要消耗一定的时间，因此重发的数据很可能已经错过了播放的时机。一旦错过播放时机，重发数据也是没有用的，因为声音和图像已经卡顿了，这是无法挽回的。

5. 完

经过这次整理，我对这本书知识有了更多的认识。明天将第三章第四章整理出来。