重读《自顶向下》---关于计算机网络的一些新认识（上）

前言

  最近这段时间，抽空又重新读了一遍《Computer Networking - A Top-Down Approach》。过程中有不少新的认识，总结如下，希望可以便人便己。

注：本文属于重读回顾性质的总结，很多理解都是来自于书籍。同时下面对网络的认识从表述形式上没有太多的章节规律（基本上是从各个网络层次这条主脉络），大都以条目形式列出， 如有阅读不适，请见谅 (/ω＼)

---

一、概论

1、接入网的几种形式?

（1） 拨号上网
（2） DSL
（3） Cable
（4） FTTH
（5） Ethernet
（6） WiFi
（7） Wide-Area Wireless Access

2、数据在网络中传输的方式?

• 电路交换: 可以使用时分复用和频分复用
• 报文交换: 可以理解为统计时分复用

3、如何理解Internet?

简单的说，可以把Internet 理解为网络连接成的网络。如下图所示。

 
4、衡量网络性能的几个指标？

• packet在传输过程中的几种延时

  • 处理延时
  • 排队延时
  • 发送延时
  • 传输延时

• 丢包率

• 吞吐量

 
5、网络安全涉及的一些内容？

• 传播恶意软件：如病毒、木马、蠕虫等
• 攻击服务器和网络基础设施，如Dos工具 ，如发送精心设计的msg、带宽洪攻击、连接攻击
• 网络监听， 如sniff packets
• 通信伪装，伪装成某一个信任的端点

 
6、请问，ip数据包经由路由转发的时候源ip，目的ip是否改变？
一般来说，包转发过程中ip地址不变，mac地址会改变。除非做了nat地址转换。从某种程度上来说，一个packet在网络传递的过程中就是从一个“局域网”跨越到另一个“局域网” （这也是把Internet看成由网络连接的网络的原因），在这个过程中，ip地址一直是不变的，而目的mac地址在每个局域网中是不同的（一般是下一条路由器的mac地址）。

具体可参考：ip数据包经由路由转发的时候源ip，目的ip是否改变

 
7、对于终端用户或者非网络人员（普通程序员）来说，终端（end system）是关注的重点，上面运行着各种各样的应用。中间的网络部分从某种程度上来说，只是提供了一种“数据传输”的服务。

 
 

二、应用层

1、网络应用的两种主要架构方案？

• CS
• P2P

 
2、 一个网络应用包括很多个组件，协议（（用于规定消息的格式和交换的时机）可能只是其中的一部分；比如说web应用包括web服务器，web客户端，html（web 网页格式），还有http协议等。
 
3、 http连接的两种方式？

• 长连接
• 短连接
   
  4、web cache 本质上是一个服务器缓存。当浏览器支持代理之时，会在一定程度上降低对原始服务器（original web server）的访问压力。 它是代理服务器的一种（proxy）（还有其他形式的代理服务器）。
   
  5、电子邮件服务的架构图

  关于smtp协议（Push方式），从发送端用户push到邮件服务器

 和POP3、IMAP和HTTP的关系（Pull方式），接收端通过pull方式从服务器段拉取

6、smtp邮件协议和http协议的区别？
从某种程度上来说，和http协议一样，smtp也是一种文件传输协议。但他们也有些区别
（1） http协议主要是采用pull方式来传输文件。而smtp相对来说采用的是push的方式来发送邮件
（2） smtp协议需要每个message必须是ASCII类型的，如果消息中存在二进制类型的数据，那么必须要进行重新进行编码。而http则无此限制
（3） 如果一个文件中包含text和image, 那么对于http来说，它把这两种数据当成不同的object来分别传送。而smtp则把它们放在同一个message中传输。

 
7、DNS的几种作用

• 域名解析
• host aliasing (主机别名)
• 负载均衡

 
8、DNS的记录格式

9、对于DNS来说，从宏观上来看，它是一个分布式的数据库。这个数据库的数据遍布在全球的很多地方。 之所以设计成成去中心化的，是因为中心化的数据库有以下几个问题：
（1） 单点失败问题（a single point of failure）
（2） 性能问题（performance problem）。包括请求负载压力和dns的巨大容量问题
（3） 遥远的距离问题（distant centralized database）。 即，不同的访问dns服务的距离不同，无法利用分布式多server的近距离优势

 
 

三、传输层

1、传输层可以提供给应用层的服务

• 可靠传输
• 吞吐量保证（即保证一定的吞吐量）
• 时序（即保证一定的时序规则）
• 安全性保证

 
2、TCP提供的服务

• 面向连接
• 可靠数据传输（面向的是host）
• 拥塞控制 （面向的是整个网络）

 
3、UDP提供的服务

• 尽最大的可能传输数据（即，可能会有数据丢失和数据的unorder）

 
4、TCP提供的可靠的数据传输到底有多可靠？

    这里所说的tcp提供的可靠性主要指的是发送端发送的数据和接收端接受到的数据是不是一样的。换言之，会不会因为硬件或者软件错误导致传输的数据出错（某个bit或者某个组合的bit出错）而却能通过层层的监测机制（以太网的crc校验、网路层的ip checksum 和tcp 层的checksum）

答案是，可以。也就是说tcp虽然是个可靠的数据传输机制，但不是完全绝对的可靠传输，也就是说有可能（当然可能性很小）发送端发送的数据和接收端接受的数据不一致。

一般说来，对于严格的网络应用来说，都需要在应用层加上自己的一套检测机制，如md5、checksum等。

当然，按照我的理解，即使是应用层加上了检测机制，虽然可以很大程度上降低出错的可能，但是概率上能不能降到0，还是个问题。我没找到确切的答案，如果有小伙伴了解的，欢迎指教。

下面【2】-【6】是相关的资料。

 
5、原生的TCP是不提供安全数据传输的服务（如加密等），但是改进版的tcp，如ssl（也有的把ssl当成应用层的功能）可以提供安全传输数据的服务。应用层如果想要使用ssl服务的话，一般需要在应用层代码中包含对应的库。

 
6、现在的Internet上，传输层并没有提供吞吐量和时序的保证，所以对于低延时要求的应用来说，应用层就需要额外考虑这点。

 
7、关于端口复用的一些问题？
  对于一般的网络程序来说，一个socket可以确定一对connection 端，其中ip主要用来确定host，而port主要用来确定host中运行的网络进程。但是现在的操作系统中大都提供了端口复用的功能，也就是说多个进程可以共享一个port, 或者说多个进程可以绑定到一个ip+port上，以此来提高网络程序的性能。对于这种情况，操作系统如何知道把请求转发给哪个进程呢？ 按照我的理解，操作系统会把多个绑定到同一个port的进程（准确的来说是socket ）做一个记录，当请求到来之时，会尽可能平均的把请求转发给记录中的socket（Round-Robin ?），从内核的角度来达到负载均衡的作用。

 

---

最近在看influx 源码的时候，发现其内部的tcp服务还使用了应用层次的端口复用，即用一个总的listener 来监听端口，接受数据，然后根据第一个字节进行判断，把请求分发给对应的子listener（复用过程只存在连接accept阶段）。

现在理解这种复用（尤其是软件层面）机制，本质上就像是一种switch…case…的逻辑。由一个总的入口，然后通过一个标识（可能是在协议的报文中（比如说port端口号），也可能是在内核中，还可能是在应用层面上（比如这里接受数据的第一个字节））进行switch, 转发给最终的handler。

 
8、对于socket来说，listen 阶段的socket在 程序退出时，是直接从listen 状态直接变为close状态吗？

    这里要注意，一般来说对于服务器端程序，处于listening 状态的socket （简称为listenFd） 和之后accept 的socket（connFd）并不是同一个socket连接，前者接受客户端的连接，后者进行具体后续的通信。对于前者来说，按照我的理解，当关闭了这个listenFd之后它是不会进入到time_wait的状态，应该是直接就close了。 对于后者connFd来说，如果关闭了这个socket，那么这个socket会进入到time_wait的状态。
同时，需要注意的是，在进行三次握手的时候，这个listenFd会一直处于listening状态，它不会因为客户端发来syn连接请求而进入SEND_RCV。真正进入到SEN_RCV状态的应该是另一个半连接状态的socket（也就是后来被accept的socket）。也就是说，按照我的理解，listenFd一般只会处于listening状态和close状态。

以上的想法均是个人见解，如果有问题的话，欢迎指正(* ^ ▽ ^ *)。

 
9、推拉是种哲学。对于抽象的数据传输来说，

• 推数据的方式方便了推端，但是对端需要有一种机制在“候着”，准备接受数据。同时，这种方式在实时性较高。
• 拉数据的方式方便了拉端，但是对端需要有一种机制在“候着”，准备传送数据。这种方式是根据拉端的需求进行你那个传送，但是相对来说在信息的实时性方面不够高。

 
10、 一般来说，运输层提供的服务要以其下面几层提供的服务为基础。如果网络层不提供某种服务，比如说吞吐量和延时保证，那么运输层也不会提供这样的服务。但是也有例外，就是网络层不提供可靠的服务，但是运输层通过一些机制向上层提供了可靠传输的服务。
 
11、网络层提供的是host to host的服务，运输层提供的最基础的服务需要是process to process的服务。同时，运输层还可能提供一些其他的服务，如错误检测（udp和tcp），可靠传输(tcp)等等
 
12、UDP是无连接的，它只需要（dst ip 和dsp port）这样一个二元组就可以确定一个socket，换句话说，一般来看，udp只    有一个socket,所有的数据包（无论源ip和源port是否相同）都会发向这一个socket（只要其目的ip和目的port相同）； 而TCP是面向连接的，对于服务端来说，每accept一个请求就会创建一个新的socket，这样的话，光凭（dst ip 和dsp port） 是无法确定具体的socket的，需要加上src ip 和src port 才可以。
从某种程度上来看，可以认为tcp在udp上又多了一层。
 
13、需要说明的是，在理论上可靠数据传输服务可以由数据链路层、网络层、传输层甚至应用层实现。但是在运输层实现这个功能相对来说比较好些。
 
14、udp服务的优势

• 应用层可以更快的发送数据（tcp发送到缓冲区之后，最终什么时候发送还得看网络的traffic）
• 不需要建立连接，想发送数据直接发送
• 无连接的状态，即host中不需要保存连接的状态信息
• 头部开销较小
   

15、比起IP来说，UDP提供了最基础的process to process 服务（还有一丁点错误处理的功能，即可选的checksum，之所以还提供error check的功能，是因为有的udp 的底层协议有可能不提供error check的功能。 ）

 
16、如果想使用udp来达到可靠传输的目的，那么应用层就必须承担起类似tcp的那种重传和确认的机制。 （腾讯面试的时候经常喜欢出这样的题：“如何用udp实现一个tcp？” ）
 
17、一般来说，udp socket 没有发送缓冲区（不太确定？），只有接受缓冲区。所以对于udp来说，上层传递的数据，udp就会“蹭蹭蹭”的发出去，而不管对端是否来得及接受。 而对于接收端来说，如果发送端的数据超过了接受缓冲区的大小，整个报文就会被丢弃，无论这个报文是否可以接受一部分。
 
18、一般来说，udp在接收数据的时候是按照报文来接受的，一次read一个报文段，接受的报文和报文是不会合并的。
 
19、可靠传输的几个模型

• ARQ：停止等待协议
• GBN（Go-Back-N协议）:滑动窗口协议
• SR（select repeat）:选择重传机制

20、网络传输模型: 对于只有bit error 没有packet loss 的通道来说来说，如何保证可靠传输？
  采用ACK确认机制

21、网络传输模型:对于既有bit error 也有packet loss 的传输通道来说，如何保证可靠传输呢？
  重传机制，序列号机制

22、可靠传输涉及到的机制有哪些？

• 重传、序列号、ACK确认
• 定时器（重传需要）、checksums(重传需要)

23、 GBN 和SR协议最大的不同是什么？

对于GBN协议来说，其接收方的窗口大小为1，即只能ACK最小的那个还未acknowledge的packet, 即使接受到更大seq num 的packet.；对于SR来说，其接收方的大小为N, 可以ack 接受窗口内的N个packet. 但是发送方需要为发送窗口内的每个packet 设置一个定时器，哪个定时器timeout 了，就重新发送那个packet.
 
24、对于发送方来说，超时重传的time 一般是挺长的，所以为了加快让发送方处理到已经发送的某个packet 可能丢失，发送方一般会采用快重传的机制-收到连续的三个相同ACK, 就进行重传响应的报文。
  
25、对于现实中的tcp协议来说，它是GNB（回退N步）还是SR(选择重传)协议呢？

TCP 确认是采用累积确认方式，并且对失序报文不会给出确认。这让 TCP 看起来像是一个 GBN 协议，但是与 GBN 不同的是，TCP 会缓存失序的分组。 按照书中的说法，有建议说tcp按照选择确认的机制实现， 它允许 TCP 接收方有选择地确认失序报文段 ， 而不是累积地确认最后一个正确接收的有序报文段 。 当将该机制与选择重传机制结合起来使用时(即跳过重传那些已被接收方选择性地确认过的报文段) ， TCP 看起来就很像我们通常的 SR 协议 。 所以从某种程度上来说， TCP 更像是GNB和SR的混合方式。
  
26、tcp中为什么不采用 NACK的机制，即不采用 “否定接受到某个包”的形式？
从某种程度上来说，ack代表了一种确认报文段已经收到了（可以进行累计确认）的机制，是一种肯定回复；但是对于nack来说，它代表的是某个报文段没有收到，是一种否定回复。它们都是接收方根据接收到报文段的情况被动进行的一种反馈。

如果有这样一个场景，一系列顺序（ordered）的报文段丢失了（比如所发送端发送了1-10， 但是接收端只接收到了1-5），前者可以发送端可以根据超时（接收端迟迟没发送ack）进行重传; 而后者就有点尴尬，因为不知道是发送方根本就没发送，还是在路途中丢失了。【8】

当然，现在也有一些其他协议采用nack的方式【9】，它们应是采取了其他的措施避免了这个问题。这里就不细究了。
 
27、tcp为了防止接收端的接受不及时造成的大量packet丢失，使用了流控制协议。也就是说要保证发送方发送的数据不会超过接收方目前的接收窗口的大小（接收方会持续的把其可接受的窗口大小，也就是free buffer size 发送给发送方）。
 
28、如果C端和S端同时受到建立连接的请求怎么办？ 同时收到关闭连接的请求呢？
经典的说法是如果A和B两端同时打开或者同时关闭连接，tcp的状态会发生怎样的变化？ 答案如下：

同时打开：

AB 的状态都经历了SYN_RVD和SYN_SENT。

同时关闭：

A和B的状态都和正常主动关闭连接的情况类似。

 
29、对于传输层的拥塞控制来说，如何让sender了解到网络已经拥塞了呢？
大体上有两种方式，一个是无下层网络的辅助，主要是通过丢包率和延时（tcp就是采用这种）； 还有一个就是有下层网络的辅助，下层网络可以主动提供网络的拥塞程度，甚至可以提供中间路由器的发送速率等信息。

 
30、TCP 使用receiver 返回的正常的ACK来当做网络顺畅的信号； 使用丢包事件（收到三次重复的ACK或者超时）来当做网络阻塞的信号。
 
31、 TCP拥塞控制的状态转换和cwnd的变化图：

注意，并不是只有在拥塞避免的状态才会发生丢包事件，然后进入快恢复或者慢启动； 在其他两个状态也是可以的。也就是说在慢启动状态如果发生了丢包引起的超时事件，那么拥塞窗口会降为1MSS, ssthresh 降为cwnd/2 ,重新开始慢启动状态。
 
32、对于一个网络来说，tcp是相对来说考虑到了整个网络的公平性，即控制整个网络的拥塞程度。而udp并没有拥塞控制的机制，所以如果udp和tcp在一个网络中同时存在的话，从某种程度上来说，udp的应用可能会使整个网络陷入拥塞的境地，in other way，这是对tcp是不太公平的。所以有些路由器是会关闭对udp的传递功能的。
 
33、站在上帝的视角上看，在一个网络中，如果一个application比其他的application用了更多的tcp connection， 那么从某种程度上来说 ，它是侵占了整个网络更多的带宽资源。这就有点像linux系统上的多线程一样，如果你在linux系统上开了更多的线程（在linux上线程的本质是轻量级进程，和普通单进程一起调度），那么相对来说，你是侵占了跟多的cpu资源（当热，linux操作系统对这种“侵占”会有一定的限制）
 
34、对于tcp的拥塞控制来说，如果每个连接的发送速率差不多的话，可以简单认为拥塞控制的算法对每个连接是相对公平的，无论这些连接是在什么时候开始发送数据的。

 
 

---

参考

【1】、TCP新手误区–数据校验的意义
【2】、《Linux多线程服务端编程》
【3】、The Limitations of the Ethernet CRC and TCP/IP checksums for error detection
【4】、TCP协议100%可靠吗？
【5】、为什么说 TCP/IP 是一个不确定性网络
【6】、TCP新手误区–数据校验的意义
【7】、告知你不为人知的 UDP：疑难杂症和使用
【8】、NACK vs. ACK? When to use one over the other one?
【9】、谈谈网络通信中的 ACK、NACK 和 REX