网络原理-计算机网络详解-上网内部流程分析

一、网络模型中各层的命名规范

如数据链路层（二层），一般称为帧（Frame），比如以太帧。
而 ATM（Asynchronous Transport Mode）一般称为信元（Cell）。
ATM 是欧洲人发明的，IP 是美国人发明的，两者竞争网络层的老大，最后 IP 胜出，成为当仁不让的网络层霸主。ATM 只好委身于 IP 的「淫威」之下，充当数据链路层协议。

那么网络层（三层）则使用包（Packet）的概念，比如 IP 包。

传输层有 TCP、UDP，TCP 称为报文段或段（Segment），而 UDP 则称为用户数据报或者UDP报文（Datagram）

应用层（七层）则一律使用应用层数据（Data）。

但往往也没有那么严格，经常有人用 TCP 包、UDP 包，也不会引起混淆，但还是希望各位同学能够专业化、规范化使用名称，养成一个良好习惯。

二、本地网创建过程

弄个路由器，弄个光纤猫，超五类网线，拨号上网就行了。

网线接好后，物理层就配好了，以太网速率自协商也完成了。
数据链路层也就是以太网帧。

1、设置内网IP

（1）配置路由器

用一根网线连路由器和pc，登录浏览器访问路由器的设置页面。然后修改网关IP和子网掩码，然后设置PPPOE，自动拨号上网。
比如
网关IP：192.168.1.129
子网掩码：255.255.255.128
那么路由器的网络地址为：192.168.1.128 广播地址为192.168.1.255

参看网络层之子网划分与超网

（2）配置主机IP

配置主机IP有两种方法：

方法一：登录主机，设置静态IP。

方法二：DHCP，动态获取IP，需要在路由器里面开启DHCP服务。

2、DHCP协议详解

动态主机配置协议，英文 DHCP，是英文 Dynamic Host Configuration Protocol 的缩写，属于应用层协议，使用UDP协议工作。

DHCP运行分为四个基本过程，分别为请求IP租约、提供IP租约、选择IP租约和确认IP租约。客户在获得了一个IP地址以后，就可以发送一个ARP请求来避免由于DHCP服务器地址池重叠而引发的IP冲突。

1.DHCP发现（DISCOVER）—— 请求IP租约

电脑的操作系统安装了 TCP/IP 协议栈，这个协议栈其中包含一个 DHCP 客户端进程，这个客户端进程会广播一个发现服务器的报文，格式为 UDP 封装，目的端口号为 68，源端口号为 67；

大白话：DHCP客户机以广播方式（因为DHCP服务器的IP地址对于客户机来说是未知的）发送DHCPdiscover发现信息来寻找DHCP服务器，即向地址255.255.255.255发送特定的广播信息。网络上每一台安装了TCP/IP协议的主机都会接收到这种广播信息，但只有DHCP服务器才会做出响应。

客户也可以申请它使用的最后一个IP地址（在下面的例子里为192.168.1.100）。如果该客户所在的网络中此IP仍然可用，服务器就可以准许该申请。否则，就要看该服务器是授权的还是非授权的。授权服务器会拒绝请求，使得客户立刻申请一个新的IP。非授权服务器仅仅忽略掉请求，导致一个客户端请求的超时，于是客户端就会放弃此请求而去申请一个新的IP地址。

2.DHCP提供（OFFER）——提供IP租约

当DHCP服务器收到一个来自客户的IP租约请求时，它会提供一个IP租约。DHCP为客户保留一个IP地址，然后通过网络单播一个DHCPOFFER消息给客户。该消息包含客户的MAC地址、服务器提供的IP地址、子网掩码、租期以及提供IP的DHCP服务器的IP。并以单播方式发给客户端，目的端口号为 67，源端口号为 68 ;

服务器基于在CHADDR字段指定的客户硬件地址来检查配置。这里的服务器，192.168.1.1，将IP地址指定于YIADDR字段。，

3.DHCP请求（REQUEST）——选择IP租约

当客户PC收到一个IP租约提供时，它必须告诉所有其他的DHCP服务器它已经接受了一个租约提供。因此，该客户会发送一个DHCPREQUEST消息，其中包含提供租约的服务器的IP。当其他DHCP服务器收到了该消息后，它们会收回所有可能已提供给客户的租约。然后它们把曾经给客户保留的那个地址重新放回到可用地址池中，这样，它们就可以为其他计算机分配这个地址。任意数量的DHCP服务器都可以响应同一个IP租约请求，但是每一个客户网卡只能接受一个租约提供。

4.DHCP确认（Acknowledge，ACK）——确认IP租约

当DHCP服务器收到来自客户的REQUEST消息后，它就开始了配置过程的最后阶段。这个响应阶段以单播方式发送一个DHCPACK包给客户。这个包包含租期和客户可能请求的其他所有配置信息。
客户端接收到服务器的确认，会尝试将获得的 IP 参数配置到 TCP/IP 协议栈，还会尝试 ARP 广播请求自己的 IP 所对应的 MAC 地址，如果没有收到任何回复，说明这个 IP 地址在广播域里是唯一的，不会引起 IP 地址冲突，可以完成配置工作。

以上 DHCP 能够正常工作，有一个前提条件，那就是客户端与服务器在一个广播域内，一个广播域意味着一个网段，换句话说，一个网段需要一个 DHCP 服务器，这个对于拥有成百上千网段的大型网络来说，则需要成百上千的 DHCP 服务器，这显然不现实。

⬇️⬇️⬇️ 其他过程补充如下：⬇️⬇️⬇️

5.重新登录 （DHCPrequest）
    以后DHCP客户机每次重新登录网络时，就不需要再发送DHCPdiscover发现信息了，而是直接发送包含前一次所
分配的IP地址的DHCPrequest请求信息。当DHCP服务器收到这一信息后，它会尝试让DHCP客户机继续使用原来的IP
地址，并回答一个DHCPack确认信息。如果此IP地址已无法再分配给原来的DHCP客户机使用时（比如此IP地址已分
配给其它DHCP客户机使用），则DHCP服务器给DHCP客户机回答一个DHCPnack否认信息。当原来的DHCP客户机收到此
DHCPnack否认信息后，它就必须重新发送DHCPdiscover发现信息来请求新的IP地址。

6.更新租约
    DHCP服务器向DHCP客户机出租的IP地址一般都有一个租借期限，期满后DHCP服务器便会收回出租的IP地址。如
果DHCP客户机要延长其IP租约，则必须更新其IP租约。DHCP客户机启动时和IP租约期限过一半时，DHCP客户机都会
自动向DHCP服务器发送更新其IP租约的信息。

7.获取配置参数（DHCPINFORM）
   如果客户通过别的手段获得了网络地址，它可以使用DHCPINFORM请求获得其它配置参数，服务器接收
到DHCPINFORM包，并建立一个DHCPACK消息，在其中包括一些合适客户的配置参数，只是不包括分配网络
地址，检查现有的绑定，在信息中不填充'yiaddr'字段或租用时间参数。服务器取得DHCPINFORM包内的
'ciaddr'地址，而返回DHCPACK包。

5、DHCP中继问题

以上 DHCP 能够正常工作，有一个前提条件，那就是客户端与服务器在一个广播域内【毕竟发的是255.255.255.255广播帧】，一个广播域意味着一个网段，换句话说，一个网段需要一个 DHCP 服务器，这个对于拥有成百上千网段的大型网络来说，则需要成百上千的 DHCP 服务器，这显然不现实。
有没有现实一点的解决方案呢？比如在一个企业网只需要一台 DHCP 服务器？
问题就来了，客户端与服务器不在一个网段，客户端如何通过广播发现服务器呢？要知道，广播报文无法跨越不同网段！
这个其实不难，只是需要一个角色来协助客户端与服务器发现彼此，这个角色名字叫 DHCP 中继代理。

* DHCP 中继代理（DHCP Relay Agent）

设想是这样的，每个网段都配置一个 DHCP 中继代理，DHCP 中继预先静态配置 DHCP 服务器的 IP 地址，DHCP 中继代理自然可以接收到本网段的客户端 DHCP 广播报文，然后将广播报文修改成单播报文，目的 IP 地址为 DHCP 服务器，源 IP 地址为代理自己的，然后单播发送给服务器，服务器的回复自然也是单播发给代理，代理再将服务器的回复以单播的方式发给客户端。
通俗地说，DHCP 中继代理就是让客户端与服务器相互发现彼此的中介结构。
下面我们举一个例子来说明。
小明打开电脑，运行于后台的 DHCP 客户端，帮助小明拿到了 10.1.1.2/24 这个地址，小美拿到了 10.1.1.3/24 这个地址，小丽却拿到了 10.1.2.2/24 这个地址。请问，小明、小美在一个网段，为何小丽却在另外一个网段，这是如何做到的？
谜底就是：小明、小美在一个广播域，在这个广播域里还有他们的网关，地址是 10.1.1.1/24，已经静态配置好了，网关充当 DHCP 中继代理的角色。除了以上介绍的将接收到的 DHCP 客户端，发现服务器的广播，转换成单播以外，还在 DHCP 报文内部填写了一个字段：「中继代理=10.1.1.1」，这样服务器就可以依据中继代理的地址，找到网段 10.1.1 地址池，然后找出空闲的地址就可以分配给小明、小美了。
同样的原理，小丽的 DHCP 广播被网关（10.1.2.1/24）接收，做了以下的工作：

* 广播修改成单播，源地址为网关的地址 10.1.2.1，目的地址为 DHCP 服务器地址 10.10.10.10
* 填写 DHCP 报文中继代理字段（Gateway），这里为 Gateway = 10.1.2.1
* 重新计算 UDP 校验和

然后发送出去，到达服务器，服务器依据中继代理字段，找到另外一个地址池 10.1.2，接着就可以从空闲地址里分一个 10.1.2.2 给小丽了，然后单播回复网关 10.1.2.1，剩下的步骤可以参考上面的标准流程的四个步骤 –>【请求IP租约、提供IP租约、选择IP租约和确认IP租约】
=====================================================

假设小明、小美、他们的网关、小丽、小丽的网关连在一个交换机上，也没有配置任何虚拟局域网（VLAN）来分隔广播域，以上五者工作在一个广播域，看看 DHCP 能否正常工作？
小明的电脑发一个 DHCP 广播，用于发现广播域里的服务器，广播域里没有 DHCP 服务器，以上五者都会接收小明的广播，小明的网关、小丽的网关自然也会接收到。
于是小明网关、小丽网关都会做中继代理，填上自己的 IP 地址，到达服务器，服务器会分配两个 IP 地址，一个是 10.1.1.x，另外一个是 10.1.2.x，那小明的电脑接受哪一个呢？当然谁先到用谁的！
小明的电脑使用哪个网段地址，完全取决于哪个网关反应快，动作麻利，这种不可预测性的解决方案，不能满足企业网的安全要求。
企业网对于一个员工使用哪一个网段有严格的要求，一个网段意味着不同的权限，所以一个员工要使用真正属于他的那个网段。

综上，企业网络管理，就会采用VLAN 用来隔离广播域，对自动获取IP进行子网分段和权限控制。
=====================================================

6、DHCP与RARP的区别

RARP在功能上有点类似于DHCP协议，确切的说DHCP是BOOTP协议的升级，而BOOTP在某种意义上又是RARP协议的升级。BOOTP和RARP的区别在于RARP是在数据链路层实现的，而BOOTP实在应用层实现的，当然作为BOOTP的升级版DHCP也是在应用层实现的。
这种实现层面的差别也从RARP和BOOTP/DHCP的报文封装格式的差别上体现出来了，RARP直接封装在以太网帧中，协议类型置为0x0800以标识这个报文是ARP/RARP报文，BOOTP/DHCP报文是直接封装在UDP报文中，作为UDP的数据段出现的。
从功能上说，RARP只能实现简单的从MAC地址到IP地址的查询工作，RARP server上的MAC地址和IP地址是必须事先静态配置好的。但DHCP却可以实现除静态分配外的动态IP地址分配以及IP地址租期管理等等相对复杂的功能。

=========================================================

1）RARP可以满足主机IP地址配置的部分要求，但是不能完全满足
包括但不限于以下配置：
网络掩码，网关地址，静态路由，DNS服务器，以及私有的，公有的option功能。

2）RARP是二层协议，无法穿透子网，DHCP可以穿透子网。
好吧，那你会说有ARP代理，也可以辅助穿透子网，但是还是不好用。
因为：
ARP/RARP只能对地址进行识别，无法进行地址的统一规划和分配。
如果在一个子网内，需要对地址进行统一规划，分配和管理，以及租约，续租的管理。
必须要有一个服务器来集中管理。
因此有了bootp，有了DHCP。

我就知道还会有人说，为何不像DR,BDR路由器选举那样在用户计算机中产生一个集中管理的服务器，那是因为ARP/RARP是一个非常轻量级的协议，它设计的本意就不是这个。

另外，最重要的，用户计算机会当机，选举出来的服务器不稳定。

2.5）为何不修改ARP/RARP支持DHCP的特性?
DHCP的协议的工作本质，是动态主机配置协议，不仅仅包含IP地址配置。
TCP/IP网络的优点就是“分层”，协议各司其职。
ARP/RARP负责IP-MAC地址间的互相解析，DHCP负责管理IP层的配置。
因为，修改ARP/RARP支持DHCP，违反网络设计分层的理念。
应该去增强ARP/RARP，而不是去合并DHCP。
所以有了后来IPv6的ND。

3）既然如此为何IPv6会回归到ND（邻居发现协议），DHCPv6协同分配？
因为搞协议的人，逐渐发现，网络中有很多轻量级客户端，不需要进行统一管理，因此发明了ND，也就是增强版的ARP/RARP，它充分满足了没有DHCP服务器的情况下，在IPv6网络分配IP地址，路由前缀自动生成，快速上网的需求。

三、网络通信

大白话核心总结：

当生成完IP包，准备网络通信时，就需要判断目标主机和本机是否同网段。

如果本机和目标主机属于同一网段，

就查询本机的arp缓存表，如果存在目标主机mac地址，就直接读取，并生成两层的mac帧。如果本机的arp缓存表，没有目标主机的mac地址，那么就向本网段发送arp广播【arp请求广播只存在于本网段】，然后目标主机会发回arp单播应答给本机。这样目标主机就知道了，目标主机的mac地址了，并且将目标主机mac地址，放入本机arp缓存表。然后，本机三层ip包，封装成二层mac帧，发送给目标主机了。

如果本机和目标主机是不同网段。

首先查找本机路由表，匹配和目标主机最接近的网段号。【依据本机路由表只记录本机网段的路由，所以匹配的结果是发给默认网关】当决定IP数据包要发给默认网关时，此时检查本机arp缓存表，查询是否有网关的mac地址。如果有封装成mac帧，直接发给路由。如果没有记录网关mac地址，就发送arp广播请求，来获取网关mac地址。然后再将ip数据包组装成mac帧，发送给网关。

网关收到mac帧后，检查ip包和mac帧，发现mac地址与ip地址不匹配，不是真正发给自己的 ip包，于是查询路由表，找一个最长匹配的网络段的路由，重新组装mac帧发往下一个路由器（后面就是不断重复前面网关收到mac帧的操作发我下一个路由或目标主机）或者目标主机。【重新组装的mac帧，目标IP和源ip都不变，目标mac为下一跳的mac地址，源mac为当前网关】最终，经过几跳后，目标主机收到了mac帧。

1、访问相同网段

举例：ping 同一网段的主机。ping的协议介绍看这里

小明访问小美的电脑：比如 ping 10.1.1.3

（1）先判断小美电脑 10.1.1.3 是否和小明的电脑 10.1.1.2在同一个网段。

首先用小明的子网掩码 255.255.255.0 去和小明的IP 相与：计算出小明主机网络的网络号，即该网段的网络地址和广播地址【10.1.1.0 ，10.1.1.255】网络地址和广播地址直接的主机都属于同一网段。

然后对比目标地址：10.1.1.3 发现属于同网段。

（2）当生成三层IP包后，需要知道目标主机的mac 地址，来生成二层 mac帧。

首先查找本机的 arp缓存表，如果有，就直接读取，然后封装成mac帧，直接发给目标主机。

【关于arp缓存表和路由表，查看这里】

如果本机的arp缓存表，没有查到。就发送 arp广播请求【arp广播只存在于本网段】。

本机电脑用哪个网络接口发送arp广播请求呢？我们先了解一下本机路由表。

按照前面提到的子网划分博文，以上四条路由它们代表的网段号分别是：
127
10.1.1.2
10.1.1
0
用小美的网络号 10.1.1 与以上四条一一匹配，匹配到第三条，对应的接口为 Eth0。
于是，从接口 Eth0 发送 ARP 广播，ARP 广播在广播域里蔓延，小美的电脑也在同一个广播域可以接收到此 ARP 广播，广播请求 10.1.1.3 的硬件 MAC 地址，于是小美的电脑通过点对点单播 ARP 回复 10.1.1.2，自己的 MAC 是 MACxm，小明的电脑接收到此回复，将 10.1.1.3 / MACxm 保存在 ARP 缓存里，时间为 20—30 分钟不等，以备下次使用。

然后，本机三层ip包，封装成二层mac帧，发送给目标主机了。依照以上类似的步骤，Ping 的回包就到达本机的电脑，然后 Ping 程序软件显示，Ping 包被反弹回来，以及最大、最小、平均的来回延迟时间 RTT（Round Trip Time）。

2、访问不同网段

如果本机和目标主机是不同网段。

3、访问互联网

记录上网时，网络信息流处理过程

第一步：域名解析

互联网上网络层通信都是 IP数据包，所以小明的电脑与百度服务器的通信也是 IP 包。既然是 IP 包，则需要百度服务器的 IP 地址，小明只告诉浏览器，自己想访问的服务器的域名是 HTTP://www.baidu.com，浏览器爽快地对小明说：没有关系，我会帮你解析出服务器的 IP 地址。

浏览器通知DNS程序（进程），解析www.baidu.com 的IP。

DNS域名解析过程如下：
1）DNS 进程先检查自己的程序缓存（Cache），如果有「www.baidu.com」所对应的 IP，则直接告诉浏览器。如果缓存没有找到，进入下一步；
2）检查本地 Host 文件，看看有没有，有则告诉浏览器。如果 Host 没有找到，进入下一步；
3）检查本地的 DNS 服务器配置，得到 DNS Server = 10.10.10.10，发个消息给它，让 DNS 服务器帮助查找。
此消息为 UDP 格式，目的 IP=10.10.10.10，小明电脑发现和自己不在一个网段，于是使用前面提到的不同网段的通信，将 IP 包发给 DNS Server = 10.10.10.10；
4）DNS Server （10.10.10.10）在自己的缓存里也没有发现，于是向互联网的上级DNS Server （8.8.8.8）发送协查请求；
DNS Server （8.8.8.8）发现了匹配项：HTTP://www.baidu.com 61.135.169.125，于是将协查结果返回给小明公司 DNS 服务器（10.10.10.10），然后再返回到小明电脑（10.1.1.2）DNS 进程。
DNS 进程气喘吁吁对浏览器说：大哥，这是您要的东西（HTTP://www.baidu.com 61.135.169.125）。

第二步：浏览器 HTTP 格式打包
浏览器将小明访问服务器 HTTP://www.baidu.com 的请求打包成 HTTP 格式，然后将打包好的 HTTP 告诉 TCP 进程（程序），同时告诉 TCP 进程的还有 HTTP://www.baidu.com 的 IP（61.135.169.125）。
TCP 进程属于低调、稳健的老司机，心想，如果将浏览器发来的 IP 地址 + HTTP 直接发给 IP 进程，最后会产生一个 IP 包，但最终这个 IP 包是死是活，自己却无法知道。也许 IP 包遭遇了线路硬件故障被丢弃，或网络路径拥堵被丢弃，或者服务器压根就没有开机，最终这个 IP 包消失得无踪无影。老司机犯愁地自言自语：那可怎么办才好呢？不远处 IP 进程听到了：臣妾也不知道啊！
最终老司机想出了一个办法，先不发 HTTP，先要确保自己的 IP 包（没有任何用户数据）可以到达服务器，并且服务器的 IP 包也可以返回，这样做的好处是：
一方面，可以保证双向的路径（路由）是畅通的，没有防火墙或访问列表的阻挡；
另一方面，如果 IP 包可以返回，说明服务器是正常工作的。这样老司机的所有担忧就都一一化解了。
这个方法是如何工作的呢？

第三步：HTTP 触发 TCP 进程三次握手连接
小明 TCP 司机：老大，有空吗？想和您唠唠，听到请回答！
服务器 TCP 老司机：小明，听得到，你能听到我吗？
小明 TCP 司机：听得到！
既然双方都可以听到对方（发送 IP 包到对方，并从对方接收 IP 包），那么就可以将小明的 HTTP，使用这个三次握手建立的 TCP 连接发送出去。但是，莫急，TCP 三次握手本身也会使用 IP 进程（程序）来完成发送，由于小明电脑与服务器不在一个网段，所以是三次不同网段的通信，上文详细阐述过整个过程，不再赘述。
在 IP 进程的眼里看，三次握手就是三个 IP 包（暂不考虑超时重传）的交互，还没有传输浏览器的 HTTP 之前，已经花费了来回三个 IP 包的代价。
此时，TCP 老司机是如何传输真正的 HTTP 的呢？

第四步：TCP 传输 HTTP
这个不难，只要使用 TCP 头将 HTTP 打包起来，包的格式为 TCP + HTTP，发给 IP 进程就好了。那么，在 IP 进程眼里，只是一个 IP 包而已，IP 包的格式为 IP + TCP + HTTP。那怎么知道对方是否接收到这个 IP 包呢？
TCP 确认收货机制
对方发一个确认，喊一嗓子：IP 包已收到，那么小明 TCP 进程就放心了，喃喃自语道：收到就好……
这里还有一个问题，小明 TCP 进程如何知道是哪个 IP 包被对方确认收货？
大家都有网购经验，卖家发货时，会在外包装上打上一个序列号，当买家确认收货时（确认产品序列号），这样卖家就知道某件产品已经安全无误地到达买家手中。
TCP 将每个字节标记机制
同样的原理可以用在 IP 网络通信中。技术来源于生活，而高于生活。为了保证可靠传输，用序列号标记一下 IP 包，标记在什么地方呢？
TCP 头有一个 Sequence Number，它就是序列号，就是为了实现这个目的的，比如小明的 TCP 进程要传输 1000 字节数据，初始序列号从 1 开始，那么 Sequence Number 设置为 1，然后 TCP 把这 1000 个字节打包，然后层层地封装、传输，并最终到达服务器 TCP 进程。
TCP 确认收货方法
服务器如何确认呢？
TCP 有一个字段是专门干这个的，确认收货号 Acknowledge Number，那么这里这个 Acknowledge Number 应该是多少呢？是 1001，为什么是 1001，难道这个和一千零一夜有关？
No！
1001 是告诉对方，从初始序列号 1 开始的 1000 个字节已经成功接收，准备好接收序列号从 1001 开始的数据了，这个应该很好理解吧？
小明 TCP 进程接收到此确认收货，就安心等待服务器将 HTTP://www.baidu.com 的页面发送过来了。
这个过程一个数据、一个确认收货，一共两个 IP 包。

第五步：服务器将自己的网页回传
服务器将自己的主页封装成 HTTP 格式，为了方便表达，假定主页只需要一个 TCP 就可以传输，此过程和第四步相似，即服务器 TCP 进程发给小明电脑一个 IP 包（包含网页），小明电脑回复一个收货确认（没有任何数据，只有 IP + TCP），那么一共两个 IP 包。
简而言之，TCP 的可靠传输机制：己方数据发送，对方确认，就这么简单。
第六步：释放 TCP 连接
小明浏览器将接收到的网页输出到屏幕上，任务就基本完成了。为什么说基本完成，而不说完全完成？因为还需要将之前建立的 TCP 连接断开，有同学会疑惑，为何要释放 TCP 连接？
因为数据已经传输完毕，TCP 连接依然活得好好的，但 TCP 连接会占用资源，比如会占用 TCP 端口资源、内存资源，既然不用了，就释放出来给有需要的应用程序使用。

* 通俗解释 TCP 关闭连接

TCP 连接可以看成两个水管，一个进水管，一个出水管。
从小明 TCP 进程来看，自己发数据用的是出水管，而接收服务器的数据使用进水管，释放连接意味着将两个水管都关闭。
如果小明没有数据要发给服务器，那可以放心地关闭出水管，但不能关闭进水管，因为进水管也许还有水，或者对方还需要继续运水过来，小明贸然关闭进水管不妥，可能会造成数据丢失。
所以进水管还是让对方来关闭比较恰当，因为对方会真正知道到底还有没有水要运输！
关闭 TCP 连接的步骤：
1）小明 TCP 进程：老大，我没有水要运了，准备关闭我的出水管了，收到请确认！
2）服务器 TCP 进程：小明，你的出水管里的水已经接收完毕，可以放心关闭，确认完毕！一旦小明接收到确认，出水管就完成关闭，不能再用出水管运水了。
此时，假设服务器也没有水要运给小明了，所以决定关闭服务器的出水管。（小明的进水管）
3）服务器 TCP 进程：小明，我也没有水要运了，准备关闭我的出水管了，收到请确认！
4）小明 TCP 进程：老大，你的出水管里的水已经接收完毕，可以放心关闭，确认完毕！
一旦服务器接收到确认，出水管（小明的进水管）就完成关闭，不能再用出水管运水了，服务器 TCP 进程释放资源。
小明 TCP 进程发出去的确认，自己无从知道是否对方已经接收到，除非对方超时重传关闭出水管的消息，小明启动一个定时器等待，如果超时以内没有接收到任何重传的消息，说明对方接收到自己的确认，那就彻底关闭 TCP 连接，释放所有资源；而如果接收到对方超时重传，自己再确认，然后再等待，直到最终确认对方接收到自己的确认。
这里不考虑超时重传，为了关闭 TCP 连接，一共使用了四个 IP 包。那么整个通信过程一共使用多少个 IP 包呢？
小明举起了手：车教练，一共是十一个！
车教练循循善诱：十一个是怎么来的？
小明：建立连接是三个，双向通信是四个，释放连接是四个。
车教练：回答完全正确，小明，考试合格，可以开车上路了……

参考：
https://blog.csdn.net/u013485792/article/details/50731538
http://www.qingpingshan.com/m/view.php?aid=215832

0 0 votes

Article Rating