计算机网络-HTTP和TCPIP协议简介

admin 管理员组

文章数量: 887016

一、HTTP

1.常见名词名称简介

LAN Local Area Network 局域网

WLAN Wireless Local Area Network 无线局域网

WAN Wide Area Network 广域网

MAC Media Access Control 网卡地址

CSMA Carrier Sense Multiple Access 载波监听多路访问 允许多个设备在同一信道发送信号的协议

Bandwidth 带宽

Exponetial Back off 指数退避 共享传输时冲突等待方法

IP Internet Protocol 网络协议

ICMP Internet Control Message Protocol Internet控制报文协议 用于在IP主机、路由器之间传递控制消息 控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息，ICMP实际上是IP的一个组成部分

BGP Border Gateway Protocol 边界网关协议 和其他的 BGP 系统交换网络可达信息

Traceroute 利用ICMP 协议定位您的计算机和目标计算机之间的所有路由器。TTL 值可以反映数据包经过的路由器或网关的数量

UDP User Datagram Protocol 用户数据报协议 无连接的传输协议，不可靠、快速传输

TCP Transmission Control Protocol 传输控制协议 面向连接的、可靠的、基于字节流的通信协议

DNS Domain Name System 域名系统 将域名和IP地址相互映射的一个分布式数据库 使用UDP端口53

HTTP Hypertext Transfer Protocol 超文本传输协议 运行在TCP之上

MIME Multipurpose Internet Mail Extensions 多用途互联网邮件扩展类型 能支持非ASCII字符文本

ARP Address Resolution Protocol ARP 是一种用以解析地址的协议，根据 IP 地址反查对应 MAC 地址

RFC Request For Connect

DHCP Dynamic Host Configuration Protocol 动态主机配置协议，是一个局域网的网络协议。指的是由服务器控制一段IP地址范围，客户机登录服务器时就可以自动获得服务器分配的IP地址和子网掩码。

NAT Network Address Translation，网络地址转换，使用本地地址（私网IP地址）的主机在和外界通信时，都要在NAT路由器上将其本地地址转换成全球IP地址，才能和因特网连接。简单的示意图如下，一定要注意是转换源地址（就是当前主机暴露在公网的地址）不是转换目的地址

NAPT Network Address Port Translation，网络地址端口转换，IPv4公网地址是有限的，NAT只能解决公网和内网一对一的映射关系不能解决公网地址不足的问题。NAPT对数据包的 IP 地址、协议类型、传输层端口号同时进行转换，可以明显提高公网 IP 地址的利用率。具体可参考：NAT和NAPT。示意图如下，内部多个地址映射到同个地址，只是端口不一致。

VoIP Voice over Internet Protocol，是一种语音通话技术，经由网际协议（IP)来达成语音通话与多媒体会议，也就是经由互联网来进行通信，VoIP可用于包括VoIP电话、智能手机、个人计算机在内的诸多互联网接入设备，通过蜂窝网络、Wi-Fi进行通话及发送短信。

SIP Session Initiation Protocol，是一种源于互联网的IP 语音会话控制协议，用于创建、修改和释放一个或多个参与者的会话

SBC Session Border Controller-SBC,对会话进行管理，可参考SBC的20常用功能

2.一个HTTP请求发送和接收的大致过程

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。

IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC地址。

IP 间的通信依赖 MAC 地址。在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的 MAC地址来搜索下一个中转目标。这时，会采用 ARP 协议（AddressResolution Protocol）。ARP 是一种用以解析地址的协议，根据通信方的 IP 地址就可以反查出对应的 MAC 地址。

在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。这种机制称为路由选择（routing）。

TCP 位于传输层，提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service）是指为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方，而且 TCP 协议能够确认数据最终是否送达到对方。确保数据能到达目标为了准确无误地将数据送达目标处，TCP 协议采用了三次握手（three-way handshaking）策略。用 TCP 协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。

3.HTTP相关要点总结

1．HTTP规定在HTTP客户与HTTP服务器之间的每次交互，都由一个ASCII码串构成的请求和一个“类MIME（MIME—like）”的响应组成。HTTP报文通常都是用TCP连接。

2．从层次的角度看，HTTP是面向事务的应用层协议。所谓事务，就是指一系列的信息交换，而这一系列的信息交换是一个不可分割的整体，即要么所有信息交换都完成，要么一次交换都不进行。

3．HTTP协议本身是无连接的，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文前不需要建立HTTP连接。

4．HTTP协议时无状态的，也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同。

5．万维网客户把HTTP请求报文作为TCP连接三次握手的第三个报文的数据发送给万维网服务器，服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。

6．HTTP/1.0的主要缺点，是每请求一个文档就要有两倍RTT(Round-Trip Time)的开销。HTTP/1.1使用持续连接。所谓持续连接，就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文，这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高了。

7．HTTP/1.1协议的持续连接有两种方式，即非流水线方式和流水线方式。非流水线方式的特点是，客户在收到前一个响应后才能发出下一个请求；流水线方式的特点是，客户在收到HTTP的响应报文之前就能接着发送新的请求报文。持久连接使得多数请求以管线化（pipelining）方式发送成为可能，管线化技术出现后，不用等待响应亦可直接发送下一个请求。

8．HTTP请求报文和响应报文都由三个部分组成：开始行、首部行、实体主题。开始行用于区别报文时响应报文还是请求报文，在请求报文中，开始行叫做请求行，而在响应报文中，开始行叫做状态行。

9．请求报文请求行只有三个内容：方法、请求资源的URL、HTTP的版本。响应报文的状态行也包括三项内容：HTTP的版本、状态码、解释状态码的简单短语。HTTP 在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。通过在传输时编码，能有效地处理大量的访问请求。但是，编码的操作需要计算机来完成，因此会消耗更多的 CPU 等资源。

10．状态码都是三位数字的，分为5大类共33种，例如：

• 1xx表示通知信息的，如请求收到了或正在进行处理

• 2xx表示成功，如接受或知道了；

  • 200 : 正常请求
  • 201: 服务器接收到请求,一个新的资源已经建立
  • 202: 服务器接收到请求,新的资源尚未被建立
  • 204: 服务器已经成功处理请求,并且无需返回信息

• 3xx表示重定向，如果完成请求，还必须采取进一步的行动；

  • 300: 资源重定向
  • 301: 资源永久重定向,常用于服务器搬迁,对搜索引擎的友好提示,不会损失seo
  • 302: 资源临时从不同 url 响应
  • 303: 资源可以在另一个 url 找到,临时重定向
  • 304: 服务器已经接收到请求,但是请求的文档并未发生改变,应使用缓存的内容

• 4xx表示客户端错误，如请求中有错误的语法或不能完成；

  • 400: 语义有误,服务器无法理解
  • 401: 当前请求需要用户验证
  • 403: 服务器已经理解请求,但是拒绝连接
  • 404: 服务器没有找到对应的资源

• 5xx表示服务端错误，如服务器失效无法完成请求。

  • 500：服务端错误
  • 502：网关拒绝
  • 503：服务端超负荷/停机维护

11.HTTP/1.1首部

• 通用首部

• 请求首部

• 响应首部字段
• 实体首部字段

补充说明下几个请求头：
**host:**表示当前请求要被发送的目的地，说白了就是当前请求目标资源的host，仅包括域名和端口号，如test.haoji.me。在任何类型请求中，request都会包含此header信息。

**Origin:**表示当前请求资源所在页面的协议和域名，这个参数一般只存在于CORS跨域请求中，普通请求没有这个header。

**Referer:**表示当前请求资源所在页面的完整路径：协议+域名+查询参数

12．在浏览器地址栏键入URL，按下回车之后发生的几个事件：

1）浏览器向DNS服务器请求解析该URL中的域名所对应的IP地址；

2）解析出IP地址后，根据该IP地址和默认端口80，和服务器建立TCP连接；

3）浏览器发出读取文件（URL中域名后面部分对应的文件）的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器；

4）服务器给出相应，把对应的html文本发送给浏览器；

5）释放TCP连接；

6）浏览器将该文本显示出来。

4.HTTPS

HTTP 主要有这些不足，例举如下:

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

简单点说就是通信双方无法确认对方是可信的。

TCP/IP 是可能被窃听的网络，即使已经过加密处理的通信，也会被窥视到通信内容。HTTPS只是保证通信双方是可信的，对于具体的请求内容是可以在客户端被抓包获取的。

加密的对象可以有这么几个：

通信的加密

一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP
Secure，超文本传输安全协议）或 HTTP over SSL。

内容的加密

由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把HTTP 报文里所含的内容进行加密处理。在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。

存在的问题

HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患：

• 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
• 无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
• 无法判定请求是来自何方、出自谁手。即使是无意义的请求也会照单全收。
• 无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）
• 接收到的内容可能有误，由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。

加密技术：

• 共享密钥加密
  加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。
  以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。
• 公开密钥
  公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

公开密钥加密方式还是存在一些问题的，那就是无法证明公开密钥本身就是货真价实的公开密钥。可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书。CA认证的证书浏览器就会认为是可信的。

认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

证书既可以是用户端的也可以是服务端的。

HTTPS通信

• 步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
• 步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
• 步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
• 步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
• 步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
• 步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
• 步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
• 步骤 8： 服务器同样发送 Change Cipher Spec 报文。
• 步骤 9： 服务器同样发送 Finished 报文。
• 步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
• 步骤 11： 应用层协议通信，即发送 HTTP 响应。
• 步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）这两个协议。

HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢。

SSL 的慢分两种。

一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。
和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 连接、发送 HTTP 请求 •响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。

另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL 加速器的功效，以分担负载。

因此，如果是非敏感信息则使用 HTTP 通信，除此之外，想要节约购买证书的开销也是原因之一。

简单总结下HTTPS：普通的http请求不能确认通信双方是可信的，可能存在中间人劫持，因此，可以对通信内容进行加密，那么就算它拿到了数据也无法解密。问题是如何和服务器商定加密的秘钥。加密方式分为对称加密和非对称加密，因为非对称加密比较耗时耗费服务器性能，所以，先用非对称加密交换加通信时用的加密秘钥。客户端保存公开秘钥，服务端保存私有秘钥，那么客户端用公开秘钥对通信的加密秘钥加密后只有对应的服务端才能解密。现在问题来了，如何保证客户端加密时所用的公开秘钥是可信任的服务端的，此时，利用第三方机构的CA证书，它会用自己的私钥加密服务端的公开秘钥，CA证书对应的公钥秘钥是公开的，所以通信时，客户端收到对应的报文时，用CA证书的公开秘钥解密，如果成功说明是可信的，那么客户端就可以用这个解密后的秘钥来加密后续的通信内容。那么CA证书的公开秘钥如何保证可信呢，一般在浏览器提前内置可信的第三方机构的公开秘钥。

按道理，如果是https请求，对于密码这类敏感数据，即使在前端不加密明文传到服务器也是安全的，但是为了保险起见一般会利用非对称加密比如RSA对密码加密，后端解密后在利用其他加密方式存储在数据库中。

二、TCP/UDP

1.互联网协议入门

一、概述

1.1 五层模型

互联网的实现，分成好几层。每一层都有自己的功能，就像建筑物一样，每一层都靠下一层支持。

用户接触到的，只是最上面的一层，根本没有感觉到下面的层。要理解互联网，必须从最下层开始，自下而上理解每一层的功能。

如何分层有不同的模型，有的模型分七层，有的分四层。我觉得，把互联网分成五层，比较容易解释。

如上图所示，最底下的一层叫做"实体层"（Physical Layer），最上面的一层叫做"应用层"（Application Layer），中间的三层（自下而上）分别是"链接层"（Link Layer）、“网络层”（Network Layer）和"传输层"（Transport Layer）。越下面的层，越靠近硬件；越上面的层，越靠近用户。

它们叫什么名字，其实并不重要。只需要知道，互联网分成若干层就可以了。

1.2 层与协议

每一层都是为了完成一种功能。为了实现这些功能，就需要大家都遵守共同的规则。

大家都遵守的规则，就叫做"协议"（protocol）。

互联网的每一层，都定义了很多协议。这些协议的总称，就叫做"互联网协议"（Internet Protocol Suite）。它们是互联网的核心，下面介绍每一层的功能，主要就是介绍每一层的主要协议。

二、实体层

我们从最底下的一层开始。

电脑要组网，第一件事要干什么？当然是先把电脑连起来，可以用光缆、电缆、双绞线、无线电波等方式。

这就叫做"实体层"，它就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性，作用是负责传送0和1的电信号。

三、链接层

3.1 定义

单纯的0和1没有任何意义，必须规定解读方式：多少个电信号算一组？每个信号位有何意义？

这就是"链接层"的功能，它在"实体层"的上方，确定了0和1的分组方式。

3.2 以太网协议

早期的时候，每家公司都有自己的电信号分组方式。逐渐地，一种叫做"以太网"（Ethernet）的协议，占据了主导地位。

以太网规定，一组电信号构成一个数据包，叫做"帧"（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。

"标头"包含数据包的一些说明项，比如发送者、接受者、数据类型等等；"数据"则是数据包的具体内容。

"标头"的长度，固定为18字节。"数据"的长度，最短为46字节，最长为1500字节。因此，整个"帧"最短为64字节，最长为1518字节。如果数据很长，就必须分割成多个帧进行发送。

3.3 MAC地址

上面提到，以太网数据包的"标头"，包含了发送者和接受者的信息。那么，发送者和接受者是如何标识呢？

以太网规定，连入网络的所有设备，都必须具有"网卡"接口。数据包必须是从一块网卡，传送到另一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址。

每块网卡出厂的时候，都有一个全世界独一无二的MAC地址，长度是48个二进制位，通常用12个十六进制数表示。

前6个十六进制数是厂商编号，后6个是该厂商的网卡流水号。有了MAC地址，就可以定位网卡和数据包的路径了。

3.4 广播

定义地址只是第一步，后面还有更多的步骤。

首先，一块网卡怎么会知道另一块网卡的MAC地址？

回答是有一种ARP协议，可以解决这个问题。这个留到后面介绍，这里只需要知道，以太网数据包必须知道接收方的MAC地址，然后才能发送。

其次，就算有了MAC地址，系统怎样才能把数据包准确送到接收方？

回答是以太网采用了一种很"原始"的方式，它不是把数据包准确送到接收方，而是向本网络内所有计算机发送，让每台计算机自己判断，是否为接收方。

上图中，1号计算机向2号计算机发送一个数据包，同一个子网络的3号、4号、5号计算机都会收到这个包。它们读取这个包的"标头"，找到接收方的MAC地址，然后与自身的MAC地址相比较，如果两者相同，就接受这个包，做进一步处理，否则就丢弃这个包。这种发送方式就叫做"广播"（broadcasting）。

有了数据包的定义、网卡的MAC地址、广播的发送方式，"链接层"就可以在多台计算机之间传送数据了。

四、网络层

4.1 网络层的由来

以太网协议，依靠MAC地址发送数据。理论上，单单依靠MAC地址，上海的网卡就可以找到洛杉矶的网卡了，技术上是可以实现的。

但是，这样做有一个重大的缺点。以太网采用广播方式发送数据包，所有成员人手一"包"，不仅效率低，而且局限在发送者所在的子网络。也就是说，如果两台计算机不在同一个子网络，广播是传不过去的。这种设计是合理的，否则互联网上每一台计算机都会收到所有包，那会引起灾难。

互联网是无数子网络共同组成的一个巨型网络，很像想象上海和洛杉矶的电脑会在同一个子网络，这几乎是不可能的。

因此，必须找到一种方法，能够区分哪些MAC地址属于同一个子网络，哪些不是。如果是同一个子网络，就采用广播方式发送，否则就采用"路由"方式发送。（"路由"的意思，就是指如何向不同的子网络分发数据包，这是一个很大的主题，本文不涉及。）遗憾的是，MAC地址本身无法做到这一点。它只与厂商有关，与所处网络无关。

这就导致了"网络层"的诞生。它的作用是引进一套新的地址，使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做"网络地址"，简称"网址"。

于是，"网络层"出现以后，每台计算机有了两种地址，一种是MAC地址，另一种是网络地址。两种地址之间没有任何联系，MAC地址是绑定在网卡上的，网络地址则是管理员分配的，它们只是随机组合在一起。

网络地址帮助我们确定计算机所在的子网络，MAC地址则将数据包送到该子网络中的目标网卡。因此，从逻辑上可以推断，必定是先处理网络地址，然后再处理MAC地址。

4.2 IP协议

规定网络地址的协议，叫做IP协议。它所定义的地址，就被称为IP地址。

目前，广泛采用的是IP协议第四版，简称IPv4。这个版本规定，网络地址由32个二进制位组成。

习惯上，我们用分成四段的十进制数表示IP地址，从0.0.0.0一直到255.255.255.255。

互联网上的每一台计算机，都会分配到一个IP地址。这个地址分成两个部分，前一部分代表网络，后一部分代表主机。比如，IP地址172.16.254.1，这是一个32位的地址，假定它的网络部分是前24位（172.16.254），那么主机部分就是后8位（最后的那个1）。处于同一个子网络的电脑，它们IP地址的网络部分必定是相同的，也就是说172.16.254.2应该与172.16.254.1处在同一个子网络。

但是，问题在于单单从IP地址，我们无法判断网络部分。还是以172.16.254.1为例，它的网络部分，到底是前24位，还是前16位，甚至前28位，从IP地址上是看不出来的。

那么，怎样才能从IP地址，判断两台计算机是否属于同一个子网络呢？这就要用到另一个参数"子网掩码"（subnet mask）。

所谓"子网掩码"，就是表示子网络特征的一个参数。它在形式上等同于IP地址，也是一个32位二进制数字，它的网络部分全部为1，主机部分全部为0。比如，IP地址172.16.254.1，如果已知网络部分是前24位，主机部分是后8位，那么子网络掩码就是11111111.11111111.11111111.00000000，写成十进制就是255.255.255.0。

知道"子网掩码"，我们就能判断，任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算（两个数位都为1，运算结果为1，否则为0），然后比较结果是否相同，如果是的话，就表明它们在同一个子网络中，否则就不是。

比如，已知IP地址172.16.254.1和172.16.254.233的子网掩码都是255.255.255.0，请问它们是否在同一个子网络？两者与子网掩码分别进行AND运算，结果都是172.16.254.0，因此它们在同一个子网络。

总结一下，IP协议的作用主要有两个，一个是为每一台计算机分配IP地址，另一个是确定哪些地址在同一个子网络。

4.3 IP数据包

根据IP协议发送的数据，就叫做IP数据包。不难想象，其中必定包括IP地址信息。

但是前面说过，以太网数据包只包含MAC地址，并没有IP地址的栏位。那么是否需要修改数据定义，再添加一个栏位呢？

回答是不需要，我们可以把IP数据包直接放进以太网数据包的"数据"部分，因此完全不用修改以太网的规格。这就是互联网分层结构的好处：上层的变动完全不涉及下层的结构。

具体来说，IP数据包也分为"标头"和"数据"两个部分。

"标头"部分主要包括版本、长度、IP地址等信息，"数据"部分则是IP数据包的具体内容。它放进以太网数据包后，以太网数据包就变成了下面这样。

IP数据包的"标头"部分的长度为20到60字节，整个数据包的总长度最大为65,535字节。因此，理论上，一个IP数据包的"数据"部分，最长为65,515字节。前面说过，以太网数据包的"数据"部分，最长只有1500字节。因此，如果IP数据包超过了1500字节，它就需要分割成几个以太网数据包，分开发送了。

4.4 ARP协议

关于"网络层"，还有最后一点需要说明。

因为IP数据包是放在以太网数据包里发送的，所以我们必须同时知道两个地址，一个是对方的MAC地址，另一个是对方的IP地址。通常情况下，对方的IP地址是已知的（后文会解释），但是我们不知道它的MAC地址。

所以，我们需要一种机制，能够从IP地址得到MAC地址。

这里又可以分成两种情况。第一种情况，如果两台主机不在同一个子网络，那么事实上没有办法得到对方的MAC地址，只能把数据包传送到两个子网络连接处的"网关"（gateway），让网关去处理。

第二种情况，如果两台主机在同一个子网络，那么我们可以用ARP协议，得到对方的MAC地址。ARP协议也是发出一个数据包（包含在以太网数据包中），其中包含它所要查询主机的IP地址，在对方的MAC地址这一栏，填的是FF:FF:FF:FF:FF:FF，表示这是一个"广播"地址。它所在子网络的每一台主机，都会收到这个数据包，从中取出IP地址，与自身的IP地址进行比较。如果两者相同，都做出回复，向对方报告自己的MAC地址，否则就丢弃这个包。

总之，有了ARP协议之后，我们就可以得到同一个子网络内的主机MAC地址，可以把数据包发送到任意一台主机之上了。

五、传输层

5.1 传输层的由来

有了MAC地址和IP地址，我们已经可以在互联网上任意两台主机上建立通信。

接下来的问题是，同一台主机上有许多程序都需要用到网络，比如，你一边浏览网页，一边与朋友在线聊天。当一个数据包从互联网上发来的时候，你怎么知道，它是表示网页的内容，还是表示在线聊天的内容？

也就是说，我们还需要一个参数，表示这个数据包到底供哪个程序（进程）使用。这个参数就叫做"端口"（port），它其实是每一个使用网卡的程序的编号。每个数据包都发到主机的特定端口，所以不同的程序就能取到自己所需要的数据。

"端口"是0到65535之间的一个整数，正好16个二进制位。0到1023的端口被系统占用，用户只能选用大于1023的端口。不管是浏览网页还是在线聊天，应用程序会随机选用一个端口，然后与服务器的相应端口联系。

"传输层"的功能，就是建立"端口到端口"的通信。相比之下，"网络层"的功能是建立"主机到主机"的通信。只要确定主机和端口，我们就能实现程序之间的交流。因此，Unix系统就把主机+端口，叫做"套接字"（socket）。有了它，就可以进行网络应用程序开发了。

5.2 UDP协议

现在，我们必须在数据包中加入端口信息，这就需要新的协议。最简单的实现叫做UDP协议，它的格式几乎就是在数据前面，加上端口号。

UDP数据包，也是由"标头"和"数据"两部分组成。

"标头"部分主要定义了发出端口和接收端口，"数据"部分就是具体的内容。然后，把整个UDP数据包放入IP数据包的"数据"部分，而前面说过，IP数据包又是放在以太网数据包之中的，所以整个以太网数据包现在变成了下面这样：

UDP数据包非常简单，"标头"部分一共只有8个字节，总长度不超过65,535字节，正好放进一个IP数据包。

5.3 TCP协议

UDP协议的优点是比较简单，容易实现，但是缺点是可靠性较差，一旦数据包发出，无法知道对方是否收到。

为了解决这个问题，提高网络可靠性，TCP协议就诞生了。这个协议非常复杂，但可以近似认为，它就是有确认机制的UDP协议，每发出一个数据包都要求确认。如果有一个数据包遗失，就收不到确认，发出方就知道有必要重发这个数据包了。

因此，TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP数据包和UDP数据包一样，都是内嵌在IP数据包的"数据"部分。TCP数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必再分割。

六、应用层

应用程序收到"传输层"的数据，接下来就要进行解读。由于互联网是开放架构，数据来源五花八门，必须事先规定好格式，否则根本无法解读。

"应用层"的作用，就是规定应用程序的数据格式。

举例来说，TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了"应用层"。

这是最高的一层，直接面对用户。它的数据就放在TCP数据包的"数据"部分。因此，现在的以太网的数据包就变成下面这样。

七、一个小结

先对前面的内容，做一个小结。

我们已经知道，网络通信就是交换数据包。电脑A向电脑B发送一个数据包，后者收到了，回复一个数据包，从而实现两台电脑之间的通信。数据包的结构，基本上是下面这样：

发送这个包，需要知道两个地址：

• 对方的MAC地址
• 对方的IP地址

有了这两个地址，数据包才能准确送到接收者手中。但是，前面说过，MAC地址有局限性，如果两台电脑不在同一个子网络，就无法知道对方的MAC地址，必须通过网关（gateway）转发。

上图中，1号电脑要向4号电脑发送一个数据包。它先判断4号电脑是否在同一个子网络，结果发现不是（后文介绍判断方法），于是就把这个数据包发到网关A。网关A通过路由协议，发现4号电脑位于子网络B，又把数据包发给网关B，网关B再转发到4号电脑。

1号电脑把数据包发到网关A，必须知道网关A的MAC地址。所以，数据包的目标地址，实际上分成两种情况：

场景	数据包地址
同一个子网络	对方的MAC地址，对方的IP地址
非同一个子网络	网关的MAC地址，对方的IP地址

发送数据包之前，电脑必须判断对方是否在同一个子网络，然后选择相应的MAC地址。接下来，我们就来看，实际使用中，这个过程是怎么完成的。

八、用户的上网设置

8.1 静态IP地址

你买了一台新电脑，插上网线，开机，这时电脑能够上网吗？

通常你必须做一些设置。有时，管理员（或者ISP）会告诉你下面四个参数，你把它们填入操作系统，计算机就能连上网了：

• 本机的IP地址
  　　* 子网掩码
  　　* 网关的IP地址
  　　* DNS的IP地址

下图是Windows系统的设置窗口。

这四个参数缺一不可，后文会解释为什么需要知道它们才能上网。由于它们是给定的，计算机每次开机，都会分到同样的IP地址，所以这种情况被称作"静态IP地址上网"。

但是，这样的设置很专业，普通用户望而生畏，而且如果一台电脑的IP地址保持不变，其他电脑就不能使用这个地址，不够灵活。出于这两个原因，大多数用户使用"动态IP地址上网"。

8.2 动态IP地址

所谓"动态IP地址"，指计算机开机后，会自动分配到一个IP地址，不用人为设定。它使用的协议叫做DHCP协议。

这个协议规定，每一个子网络中，有一台计算机负责管理本网络的所有IP地址，它叫做"DHCP服务器"。新的计算机加入网络，必须向"DHCP服务器"发送一个"DHCP请求"数据包，申请IP地址和相关的网络参数。

前面说过，如果两台计算机在同一个子网络，必须知道对方的MAC地址和IP地址，才能发送数据包。但是，新加入的计算机不知道这两个地址，怎么发送数据包呢？

DHCP协议做了一些巧妙的规定。

8.3 DHCP协议

首先，它是一种应用层协议，建立在UDP协议之上，所以整个数据包是这样的：

（1）最前面的"以太网标头"，设置发出方（本机）的MAC地址和接收方（DHCP服务器）的MAC地址。前者就是本机网卡的MAC地址，后者这时不知道，就填入一个广播地址：FF-FF-FF-FF-FF-FF。

（2）后面的"IP标头"，设置发出方的IP地址和接收方的IP地址。这时，对于这两者，本机都不知道。于是，发出方的IP地址就设为0.0.0.0，接收方的IP地址设为255.255.255.255。

（3）最后的"UDP标头"，设置发出方的端口和接收方的端口。这一部分是DHCP协议规定好的，发出方是68端口，接收方是67端口。

这个数据包构造完成后，就可以发出了。以太网是广播发送，同一个子网络的每台计算机都收到了这个包。因为接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是发给谁的，所以每台收到这个包的计算机，还必须分析这个包的IP地址，才能确定是不是发给自己的。当看到发出方IP地址是0.0.0.0，接收方是255.255.255.255，于是DHCP服务器知道"这个包是发给我的"，而其他计算机就可以丢弃这个包。

接下来，DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方），UDP标头的端口是67（发出方）和68（接收方），分配给请求端的IP地址和本网络的具体参数则包含在Data部分。

新加入的计算机收到这个响应包，于是就知道了自己的IP地址、子网掩码、网关地址、DNS服务器等等参数。

8.4 上网设置：小结

这个部分，需要记住的就是一点：不管是"静态IP地址"还是"动态IP地址"，电脑上网的首要步骤，是确定四个参数。这四个值很重要，值得重复一遍：

• 本机的IP地址
• 子网掩码
• 网关的IP地址
• DNS的IP地址

有了这几个数值，电脑就可以上网"冲浪"了。接下来，我们来看一个实例，当用户访问网页的时候，互联网协议是怎么运作的。

九、一个实例：访问网页

9.1 本机参数

我们假定，经过上一节的步骤，用户设置好了自己的网络参数：

• 本机的IP地址：192.168.1.100
  　　* 子网掩码：255.255.255.0
  　　* 网关的IP地址：192.168.1.1
  　　* DNS的IP地址：8.8.8.8

然后他打开浏览器，想要访问Google，在地址栏输入了网址：www.google。

这意味着，浏览器要向Google发送一个网页请求的数据包。

9.2 DNS协议

我们知道，发送数据包，必须要知道对方的IP地址。但是，现在，我们只知道网址www.google，不知道它的IP地址。

DNS协议可以帮助我们，将这个网址转换成IP地址。已知DNS服务器为8.8.8.8，于是我们向这个地址发送一个DNS数据包（53端口）。

然后，DNS服务器做出响应，告诉我们Google的IP地址是172.194.72.105。于是，我们知道了对方的IP地址。

9.3 子网掩码

接下来，我们要判断，这个IP地址是不是在同一个子网络，这就要用到子网掩码。

已知子网掩码是255.255.255.0，本机用它对自己的IP地址192.168.1.100，做一个二进制的AND运算（两个数位都为1，结果为1，否则为0），计算结果为192.168.1.0；然后对Google的IP地址172.194.72.105也做一个AND运算，计算结果为172.194.72.0。这两个结果不相等，所以结论是，Google与本机不在同一个子网络。

因此，我们要向Google发送数据包，必须通过网关192.168.1.1转发，也就是说，接收方的MAC地址将是网关的MAC地址。

9.4 应用层协议

浏览网页用的是HTTP协议，它的整个数据包构造是这样的：

HTTP部分的内容，类似于下面这样：

GET / HTTP/1.1
　　Host: www.google
　　Connection: keep-alive
　　User-Agent: Mozilla/5.0 (Windows NT 6.1) …
　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
　　Accept-Encoding: gzip,deflate,sdch
　　Accept-Language: zh-CN,zh;q=0.8
　　Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
　　Cookie: … …

我们假定这个部分的长度为4960字节，它会被嵌在TCP数据包之中。

9.5 TCP协议

TCP数据包需要设置端口，接收方（Google）的HTTP端口默认是80，发送方（本机）的端口是一个随机生成的1024-65535之间的整数，假定为51775。

TCP数据包的标头长度为20字节，加上嵌入HTTP的数据包，总长度变为4980字节。

9.6 IP协议

然后，TCP数据包再嵌入IP数据包。IP数据包需要设置双方的IP地址，这是已知的，发送方是192.168.1.100（本机），接收方是172.194.72.105（Google）。

IP数据包的标头长度为20字节，加上嵌入的TCP数据包，总长度变为5000字节。

9.7 以太网协议

最后，IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。

以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），所以四个包的IP数据包的长度分别为1500、1500、1500、560。

9.8 服务器端响应

经过多个网关的转发，Google的服务器172.194.72.105，收到了这四个以太网数据包。

根据IP标头的序号，Google将四个包拼起来，取出完整的TCP数据包，然后读出里面的"HTTP请求"，接着做出"HTTP响应"，再用TCP协议发回来。

本机收到HTTP响应以后，就可以将网页显示出来，完成一次网络通信。

这个例子就到此为止，虽然经过了简化，但它大致上反映了互联网协议的整个通信过程。

2.TCP连接的建立和释放

1.TCP首部格式
先看TCP报文段的格式，如下;

TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项。因此TCP报文段的最小长度为20个字节。

首部固定部分的各字段的意义如下：

1、源端口和目的端口：加上IP首部的源IP地址和目的IP地址，确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序，从而实现TCP的分用功能。

2、序号：占4个字节，序号的范围为[0,4284967296]。由于TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号。另外，序号是循环使用的，当序号增加到最大值时，下一个序号就又回到了0。

3、确认号：当ACK标志位为1时有效，表示期望收到的下一个报文段的第一个数据字节的序号。确认号为N，则表明到序号N-1为止的所有数据字节都已经被正确地接收到了。

4、头部长度：TCP报文段的头部长度，它指出TCP报文段的数据部分的起始位置与TCP报文段的起始位置的距离。头部长度占4位，但它的单位是32位字，即以4字节为计算单位，因此头部长度的最大值为15*4=60个字节，这就意味着选项的长度不超过40个字节。

5、保留位：必须为0.

6、下面的六个控制位说明报文段的性质：

• URG：与首部中的紧急指针字段配合使用。URG为1时，表明紧急指针字段有效，发送应用进程告诉发送方的TCP有紧急数据要传送，于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而其后面仍是普通数据。
• ACK：仅当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。TCP规定，在连接建立后所有的传送报文段都必须把ACK置1。
• PSH：如果发送的报文段中PSH为1，则接收方接受到该报文段后，直接将其交付给应用进程，而不再等待整个缓存都填满后再向上交付。
• RST：复位标志，RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后重新建立运输连接。
• SYN：同步序号，用来发起一个连接。当SYN=1而ACK=0时，表明这是一个连接请求报文段，若对方同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。
• FIN：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放连接。
• 窗口：接收方让发送方下次发送报文段时设置的发送窗口的大小。
• 校验和：校验的字段范围包括首部和数据这两部分。
• 紧急指针：紧急指针当URG=1时才有效，它指出本报文段中的紧急数据的字节数。值得注意的是，即使窗口为0时，也可发送紧急数据。
• 选项与填充：选项应该为4字节的整数倍，否则用0填充。最常见的可选字段是最长报文大小MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。该选项如果不设置，默认为536（20+20+536=576字节的IP数据报），其中ip首部和tcp首部各20个字节，而internet 上标准的MTU （最小）为576B。

2.TCP连接的建立
下图为TCP三次握手连接的建立过程：

如果想直接关闭，可用shutdown方法

服务端的TCP进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务端进程处于LISTEN状态，等待客户端的连接请求，如有，则作出响应。

1、客户端的TCP进程也首先创建传输控制模块TCB，然后向服务端发出连接请求报文段，该报文段首部中的SYN=1，ACK=0，同时选择一个初始序号seq=i。TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN—SENT（同步已发送）状态，这是TCP连接的第一次握手。

2、服务端收到客户端发来的请求报文后，如果同意建立连接，则向客户端发送确认。确认报文中的SYN=1，ACK=1，确认号ack=i+1，同时为自己选择一个初始序号seq=j。同样该报文段也是SYN=1的报文段，不能携带数据，但同样要消耗掉一个序号。这时，TCP服务端进入SYN—RCVD（同步收到）状态，这是TCP连接的第二次握手。

3、TCP客户端进程收到服务端进程的确认后，还要向服务端给出确认。确认报文段的ACK=1，确认号ack=j+1，而自己的序号为seq=i+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，因此，如果不携带数据，则下一个报文段的序号仍为seq=i+1。这时，TCP连接已经建立，客户端进入ESTABLISHED（已建立连接）状态。这是TCP连接的第三次握手，可以看出第三次握手客户端已经可以发送携带数据的报文段了。

当服务端收到确认后，也进入ESTABLISHED（已建立连接）状态。

双方同时主动连接的TCP连接建立过程
正常情况下，传输连接都是由一方主动发起的，但也有可能双方同时主动发起连接，此时就会发生连接碰撞，最终只有一个连接能够建立起来。因为所有连接都是由它们的端点进行标识的。如果第一个连接请求建立起一个由套接字（x,y）标识的连接，而第二个连接也建立了这样一个连接，那么在TCP实体内部只有一个套接字表项。

当出现同时发出连接请求时，则两端几乎在同时发送一个SYN字段置1的数据段，并进入SYN_SENT状态。当每一端收到SYN数据段时，状态变为SYN_RCVD，同时它们都再发送SYN字段置1，ACK字段置1的数据段，对收到的SYN数据段进行确认。当双方都收到对方的SYN+ACK数据段后，便都进入ESTABLISHED状态。图10-39显示了这种同时发起连接的连接过程，但最终建立的是一个TCP连接，而不是两个，这点要特别注意。

从图中可以看出，一个双方同时打开的传输连接需要交换4数据段，比正常的传输连接建立所进行的三次握手多交换一个数据段。此外要注意的是，此时我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

为什么一定要进行三次握手呢？

前两次的握手很显然是必须的，主要是最后一次，即客户端收到服务端发来的确认后为什么还要想服务端再发送一次确认呢？这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。

考虑如下的情况：客户端发送了一个连接请求报文段到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段该服务端，而后正常建立连接，数据传输完毕，并释放了连接。如果这时候第一次发送的请求报文段延迟了一段时间后，又到了服务端，很显然，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。假设不采用三次握手，这时服务端只要发送了确认，新的连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

简单讲就是，如果只有二次，网络延迟导致重发请求后，服务端返回确认就算建立连接，但客户端实际并没有发起请求，所以只能等待服务端判定客户端下线才会断掉连接，浪费了服务器的资源。如果是三次握手，那么还要客户端再次确认才会建立连接。

3.TCP连接的释放
下图为TCP四次挥手的释放过程：

数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在客户端和服务端都处于ESTABLISHED状态。

1、客户端A的TCP进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭TCP连接。释放连接报文段中FIN=1，序号为seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号加1。这时，A进入FIN—WAIT-1（终止等待1）状态，等待B的确认。TCP规定，FIN报文段即使不携带数据，也要消耗掉一个序号。这是TCP连接释放的第一次挥手。

2、B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号加1。然后B进入CLOSE—WAIT（关闭等待）状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。

3、A收到B的确认后，就进入了FIN—WAIT（终止等待2）状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态B可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号加1。这时B进入LAST—ACK（最后确认）状态，等待A的确认，这是TCP连接的第三次挥手。

4、A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME—WAIT（时间等待）状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态，时间MSL叫做最长报文寿命，RFC建议设为2分钟，因此从A进入TIME—WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。

双方主动关闭的TCP连接释放流程

与可以双方同时建立TCP传输连接一样，TCP传输连接关闭也可以由双方同时主动进行（正常情况下都是由一方发送第一个FIN数据段进行主动连接关闭，另一方被动接受连接关闭）

当两端对应的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FIN WAIT 1状态。任意一方收到对端发来的FIN数据段后，其状态均由FIN WAIT 1转变到CLOSING状态，并发送最后的ACK数据段。当收到最后的ACK数据段后，状态转变化TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终释放整个TCP传输连接。

为什么A在TIME—WAIT状态必须等待2MSL时间呢？

• 为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失，因而使处于在LIST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B可能会重传这个FIN+ACK报文段，而A就在这2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接，到CLOSED状态，那么久无法收到B重传的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，B就无法正常进入CLOSED状态。
• 防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该插口（插口是IP和端口对的意思，socket）定义的连接在这段时间内将不能被再用（就是在此期间不会有一个一样的连接存在），这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

补充：

当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

3.数据链路层

数据链路层主要有三个目的：

• 为IP模块发送和接受IP数据报；

• 为ARP模块发送ARP请求和接受ARP应答；

• 为RARP发送RARP请求和RARP应答。

  这里的ARP协议主要用来将32bit的IP地址解析为对应48bit（以太网中）的MAC地址（硬件地址）。而RARP协议则是将硬件地址解析为IP地址，这两个协议位于网络层，和IP数据报一样，都具有各自的以太网数据帧类型（即传入到以太网中要加上对应的MAC帧）。

局域网中的ARP攻击是通过伪造IP地址和MAC地址实现ARP欺骗，能够在网络中产生大量的ARP通信量，使网络阻塞。

TCP/IP支持多种不同的数据链路协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI、RS-232串行线路等，当今TCP/IP采用的主要局网技术是以太网。

最大传输单元MTU：
数据链路层中的网络对数据帧的长度都有一个限制，不同网络的MTU值不同，常用的以太网为1500个字节，一些其他网络的MTU字节值如下表：

MTU主要是为了限制一次传输的最大IP数据报的值，如果IP层有一个数据报要传，而且数据产度比数据链路层的MTU大，则就需要将IP数据报进行分片，使每一片都小于MTU。

路径MTU：

当在同一网络上的两台主机互相进行通信时，该网络的MTU是非常重要的，但如果两台主机之间的通信要经过多个网络，而每个网络的链路层可能有不同的MTU，这时，要重点考虑的是两台通信主机路径中各网络的最小MTU，称它为路径MTU。

两台主机之间的路径MTU把有一定是个常数，它取决于当时所选择的路由，而且选路不一定是对称的，即从A到B经过的路由和从B到A经过的路由不同，因此路径MTU在两个方向上不一定是一致的。

4.IP协议、ARP协议、RARP协议

IP数据报

IP是TCP/IP协议族中最核心的协议，所有的TCP、UDP、ICMP、IGMP数据都以IP数据报的格式传输。IP仅提供尽力而为的传输服务，如果发生某种错误，IP会丢失该数据，然后发送ICMP消息给信源端。另外，IP数据报可以不按发送顺序接受。

IP数据报的格式如下：

前20字节和紧接其后的选项部分是IP数据报的首部，前20个字节是固定的，选项可有可无。首部的每一行是一个32位字的单位，最高位在左边，为0bit，最低位在右边，为31bit。4字节的32bit值按照以下次序传输：首先0-7bit，其次8-15比特，然后16-23bit，最后是24-31bit，这种传输次序称为big endian字节序（我们在C语言写位操作的算法时常用到该词）。TCP/IP首部中的所有二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序，其他形式存储的二进制数据，如little endian格式，则必须在传输数据之前把首部转化成网络字节序。

首部长度是指首部占32bit字的数目，因为4位的最大值为15，因此首部最长为60字节，也即是说选项部分的最大值为40字节，不够4的倍数，要用0填充，使数据部分的起始地址为4的倍数。

总长度指整个IP数据报的长度，包括首部和数据部分，16bit，最长可达65535字节。尽管理论上可以传送一个长达65535的IP数据报，但实际上还要考虑网络的最大承载能力等因素，标准的TCP/IP分组大小为576字节，减去IP首部的20个字节，TCP首部的20个字节，路由协议头的24个字节，为512字节，因此主机接受的数据报的数据部分一般不超过512个字节。

很多基于UDP协议的应用之所以要求UDP的数据部分不超过512个字节（576-20-20），主要是考虑整个传输路径上的效率，因为链路层为X2.5的网络的MTU为576个字节，这基本也是各种链路层网络的最小MTU，大于这个值就不会产生分片，之所以建议不超过这个值应该是考虑到网络承载能力和传输效率、每台主机的接受能力等很多因素的权衡。当然书上也说，576只是建议值，实际上大于它也是可以的，只是这样在遇到X2.5网络时可能产生分片。

3个标志位主要用来标识分片的IP数据报，片位移为分片的数据报的首个字节偏离整个原始数据报的位置。

IP路由选择

主机通过路由器和目的主机连接。主机通过IP数据报连接目的主机时，按照如下步骤搜索（同一网络中的搜索要经过ARP协议将目的主机的IP地址解析为MAC地址）：

• 搜索路由表，优先搜索匹配主机，如果能找到和IP地址完全一致的目标主机，则将该包发向目标主机
• 搜索路由表，如果匹配主机失败，则匹配同子网的路由器，这需要子网掩码的协助。如果找到路由器，则将该包发向路由器。
• 搜索路由表，如果匹配同子网路由器失败，则匹配同网号路由器，如果找到路由器，则将该包发向路由器。
• 搜索路由表，如果以上都失败了，就搜索默认路由，如果默认路由存在，则发包
• 如果都失败了，就丢掉这个包。
  子网掩码
  主机号再分成一个子网号和主机号，便将一个网络又划分成了若干子网，子网掩码与该子网中的IP地址相与，便得到该子网，另外，子网对于子网内部的路由器是不透明的，也就是说IP数据报传到该网络的网关时，网关再将该数据报传送到子网的默认路由器上，最后通过该路由器再交付给该主机。

ARP协议和RARP协议

前面已经说过，ARP协议只用在局域网中，它用来将IP地址解析为MAC地址。局域网中的每个主机都有一个ARP缓存，它保存了最近发起的IP地址到MAC地址的映射记录，当该主机要向局域网中的某一主机发送数据时，它会先从自己的缓存中查找，看是否存在目标IP地址，如果找到，就通过映射找到它的MAC地址，从而发送过去，如果没有找到该目的IP地址，它就向该局域网内发送一个广播，广播中包含自己的IP地址、MAC地址和目的主机的IP地址，局域网内的所有主机都会收到该广播，但只有目的IP地址的主机会做出回应，并把自己的MAC地址发送给源主机，源主机收到后，在自己的ARP缓存中增加上该映射，并根据发来的MAC地址将数据发送给目的主机。
ARP高速缓存中的表项一般都要设置超时值，如果一段时间内没有与某主机通信，就将该主机对应的IP与MAC之间的映射关系去掉，下次在需要通信时，依然发送广播。

如果ARP请求是从一个网络的主机到另一个网络的主机，那么连接这两个网络的路由器就可以回答该请求，这个过程成为ARP代理。

RARP协议则刚好相反，它将MAC地址解析成为对应的IP地址，通常在DHCP中有集成，现在已很少单独使用。

5.ICMP协议、Ping、Traceroute

ICMP协议

ICMP经常被认为是IP层的一个组成部分，它是网络层的一个协议，它传递差错报文以及其他需要注意的信息，ICMP报文通常被IP层或更高层（TCP、UDP等）使用，它是在IP数据报内传输的。

ICMP报文大致分为两类：查询报文和差错报文。

先来看差错报文。当传送IP数据报发生错误时（比如主机不可达、网络不可达等），ICMP协议将会发送一个ICMP差错报文给源主机，好让主机做出相应的处理，也因此IP层以上的一些协议有可能做到可靠传输。书中给出了ICMP差错报文中的一些组合（类型和代码的组合）描述：如网络不可达、协议不可达、端口不可达等。这里说下端口不可达的意思：UDP的规则之一是，如果收到一份UDP数据报而目的端口与某个正在使用的进程不相符，那么UDP返回一个ICMP不可达报文，将报文中的类型和代码的组合设定为端口不可达。Traceroute程序就是利用端口不可达来产生ICMP差错报文的。

另外，在大多数情况下，传送IP数据报发生错误，会产生一个ICMP错误报文，但下面各种情况都不会导致产生ICMP差错报文：

• ICMP差错报文不会产生差错报文（ICMP查询报文可能会产生ICMP差错报文）；
• 目的地址是广播地址和多播地址的IP数据报；
• 作为链路层广播的数据报；
• 不是IP分片的第一片（没有端口信息）
• 源地址不是单个主机的数据报。

这些规则是为了防止过去允许ICMP差错报文对广播分组影响所带来的广播风暴。再来看ICMP查询报文，查询报文主要用途有：

• 子网掩码查询；
• 时间戳查询；
• ping查询。

ping程序

ping是ICMP的一个很著名的应用。ping程序时对两个TCP/IP系统连通性进行测试的基本工具，它只利用ICMP回显请求和回显应答报文，而不用经过传输层，ping服务器一般在内核中试下ICMP的功能。当某一个网站访问不了时，我们就可以ping一下这个网站，看下连通情况。比如下图：

这里先ping到google的服务器，我们可以看到连通性不是很好，丢包率为50%，而我们又ping了下Github的服务器，连通性比较好，丢包率为0%。

Traceroute程序

Traceroute是ICMP协议的另一个重要应用，主要用来侦测源主机到目的主机之间所经过的路由的情况。Traceroute使用ICMP报文和IP首部中的TTL字段，其原理很简单，开始时发送一个TTL字段为1的UDP数据报，而后每次收到ICMP超时报文后，再发送一个TTL字段加1的UDP数据报，以确定路径中的每个路由器，而每个路由器在丢弃UDP数据报时都会返回一个ICMP超时报文，最终到达目的主机后，由于ICMP选择了一个不可能的值作为UDP端口（大于30000）。这样目的主机就会发送一个端口不可达的ICMP差错报文。

6.TCP分段与IP分片

TCP协议，即传输控制协议，与UDP协议同处于传输层，同样使用相同的网络层，但TCP提供了一种可靠的、面向连接的数据传输服务，它会在两个使用TCP的应用之间建立一个TCP连接，在该连接上进行数据的传输。

TCP通过以下方式提供可靠性：

1、应用程序被分割成TCP认为最合适发送的数据块。这点与UDP完全不同，应用程序产生的UDP数据报长度将保持不变，加上IP首部后，才会进行IP分片。

2、当TCP发出一个报文段后，它会启动一个定时器，等待目的端发确认收到这个报文段，如果没能及时收到该确认信息，则将重发这个报文段。

3、当TCP接收端收到发送端发来的TCP报文段时，它将发送一个确认，这个确认不是立即发送的，通常会推迟几分之一秒。

4、TCP将保持它首部和数据的校验和。这是一个端到端的校验和，如果收到的报文段的校验和有差错，TCP将丢弃该报文段，同时不发送确认收到的消息，从而使发送端超时重发。

5、TCP能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间，TCP的接受端只允许另一端发送接收端缓冲区所能接纳的数据，这将防止较快主机致使较慢主机的缓冲区溢出。

6、由于TCP报文段作为IP数据报来传输，IP数据报的到达可能会失序，因此TCP报文段的到达也可能失序，如果必要，TCP将对收到的数据进行重排序，将收到的数据以正确的顺序交给应用层。

7、由于IP数据报有可能发生重复，TCP的接收端必须丢弃重复的数据。

从上面几点可以看出，TCP协议保持可靠性的方式就是超时重传，这种方式很好，虽然TCP也可以通过向源主机发送各种各样的ICMP报文或者来处理这些，但这也是不可靠的，试想，如果ICMP报文在发送回来的过程中丢失了，很明显这种方式就不可靠了。最可靠的方式就是只要得不到确认，就重新发送数据，直到得到确认为止。

我们在学习TCP/IP协议时都知道，TCP报文段如果很长的话，会在发送时发生分段，在接受时进行重组，同样IP数据报在长度超过一定值时也会发生分片，在接收端再将分片重组。

我们先来看两个与TCP报文段分段和IP数据报分片密切相关的概念。

MTU（最大传输单元）

MTU前面已经说过了，是链路层中的网络对数据帧的一个限制，依然以以太网为例，MTU为1500个字节。一个IP数据报在以太网中 传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。

MSS（最大分段大小）

MSS是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet上标准的MTU（最小的MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。

到了这里有一个问题自然就明了了，TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。（就是说tcp分段的报文一定满足ip分片的大小，所以tcp分段后的报文就不会再ip分片了）

再来看UDP数据报，由于UDP数据报不会自己进行分段，因此当长度超过了MTU时，会在网络层进行IP分片。同样，ICMP（在网络层中）同样会出现IP分片情况。

总结：UDP不会分段，就由IP来分。TCP会分段，当然就不用IP来分了。

另外，IP数据报分片后，只有第一片带有UDP首部或ICMP首部，其余的分片只有IP头部，到了端点后根据IP头部中的信息再网络层进行重组。而TCP报文段的每个分段中都有TCP首部，到了端点后根据TCP首部的信息在传输层进行重组。IP数据报分片后，只有到达目的地后才进行重组，而不是向其他网络协议，在下一站就要进行重组。

最后一点，对IP分片的数据报来说，即使只丢失一片数据也要重新传整个数据报（既然有重传，说明运输层使用的是具有重传功能的协议，如TCP协议）。这是因为IP层本身没有超时重传机制------由更高层（比如TCP）来负责超时和重传。当来自TCP报文段的某一段（在IP数据报的某一片中）丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报（可能有多个IP分片），没有办法只重传数据报中的一个数据分片。

7.UDP协议

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都会产生一个UDP数据报，并组装成一份待发送的IP数据报，这与面向字节流的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系（主要是在传输层就进行分段了，因此不会受IP分片的影响）。

UDP的首部一共8个字节。

UDP的校验和

至于UDP的校验和，这里注意下区别就好了，UDP对首部和数据部分都进行校验，而IP首部的校验和仅对IP的首部进行校验，顺带提下TCP，TCP的校验和也是对首部和数据部分都进行校验，另外，UDP的校验和是可选的，而TCP的是必选的。

不可靠协议

UDP是不可靠的协议，没有超时和重传功能，当UDP数据封装到IP数据报传输时，**如果丢失，会发送一个ICMP差错报文给源主机，**另外，如果UDP数据报的发送端没打开UDP校验和，而接收端计算校验和有差错，那么UDP数据报将会被丢掉，也不会发送ICMP差错报文。

路径MTU发现

可以修改Traceroute程序来确定路径MTU。要做的是发送分组，并设置将IP首部设置为不分片，发送的第一个分组的长度正好于出口MTU相等，每次收到ICMP不可分片的差错报文时，就减小分组长度，使新的ICMP不可分片差错报文中返回更小的MTU，每次用更小的MTU值来传送，这样能找到更小的MTU值。

利用路径MTU发现机制，应用程序可以充分利用更大的MTU来发送报文。

UDP最大长度

理论上IP数据报的最大长度为65535字节，因此理论上的UDP数据报的最大长度为65507（65535-20-8）字节，但是，大多数实现所提供的长度比这个最大值小。一般有两个因素的限制（书上给出了一些例子，见P120）：

1、应用程序可能受到其程序接口的限制，一些API的实现中可能有限定UDP数据报的最大长度。另外，现在大部分系统都默认提供了可读写大于8192字节的UDP数据报。

2、受限于TCP/IP内核的实现，可能存在一些实现特性，使IP数据报长度小于65535字节。

数据报截断

正是由于UDP最大数据报的限制（受限于上面的两个因素，一般都会小于65507），大于这个限制的数据报会被截断，从而发生数据丢失，且不会有任何数据丢失的通知，这也是UDP协议不可靠传输的另一个体现。而TCP则没有任何信息边界，TCP首部中没有对TCP最长报文段的限制，因此TCP以应用程序读操作时所要求的长度来传送数据（理论上一次可以发送很大的数据，但考虑到网络的传输性能，最好不要一次传输太大的数据），当然在超过MSS值时会产生分段，因此不会发生数据截断。

ICMP源站抑制差错

当一个系统中的某主机或路由器处理数据的速度赶不上接受数据的速度时，因为接收主机的IP缓存会被占满，可能会产生这个差错，从而发送一个ICMP源站抑制差错报文，这里要注意是“可能”。

8.TCP的交互数据流和成块数据流

建立在TCP协议上的应用层协议有很多，如FTP、HTTP、Telnet等，这些协议根据传输数据的多少可以分为两类：交互数据类型和成块数据类型。

交互数据类型，如：Telnet，这类协议一般只做小流量的数据交换，比如每按下一个键，要回显一些字符。

**成块数据类型，**如：FTP，这类协议需要传输的数据比较多，一般传输的数据量比较大。

针对这两种不同的情况，TCP采用不同的策略进行数据传输。

交互数据流

针对交互性要求比较高的应用，比如Rlogin远程登录中，需要回显客户端输入的字符，每发送一个字节到服务端，并回显到客户端的过程如下：

1、客户端产生一个41bit长的报文（20字节的IP首部，20字节的TCP首部，1字节的数据），发送到服务端；

2、服务端发送过来一个40bit的确认报文；

3、服务端发送回显的字符，报文长为41bit；

4、客户端发送确认报文，报文长为40bit。

如果在局域网中，通常不会有什么麻烦，因为局域网一般不会出现拥塞，但在广域网中，这些小分组则会增加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担，TCP采用了两种策略：捎带ACK和Nagle算法。

• 捎带ACK

捎带ACK的意思是，当接收端接收到TCP报文段后，并不立即发送ACK报文，而是等上一段时间，如果这段时间里该主机有数据要发送到远程主机，就将该数据捎带上ACK一起发送过去，很明显，这样可以减少传输开销。为了防止产生超时重传，绝大多数情况下，这个等待时间为200ms，超过了200ms，如果没有数据要一起发送，就直接发送ACK报文。

捎带ACK的策略一般也只有在交互性比较高的应用中才会使用，对于成块数据流，一般大多数应用程序不会同时在两个方向上发送数据。

• Nagle算法

该算法的重点是要求在TCP连接上最多只能有一个未被确认的数据报在传输。算法的大致思路如下：应用程序把要发送的数据逐个字节地发送到TCP的缓存，发送方把前面的一部分数据先发送出去，并把后面到达的字节继续缓存起来，当发送方收到前面字节的确认后，再把发送缓冲中的所有数据组装成一个报文段发送出去，同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外，Nagle算法还规定，当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时，就立即发送一个报文段。

当数据到达较快而网络速率较慢时，用这种方法可明显地减少所用的网络带宽。很明显，该算法也是专门为交互性高的应用而设计的，对于成块数据流，如果每收到一次确认才能发送下一个报文段，那么传输速率就会很低。

成块数据流
对于一些数据吞吐量要求较高的应用，总是希望每次发送尽可能多的数据到主机，对于这类应用，TCP使用滑动窗口协议，该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组，因此可以加速数据的传输。

滑动窗口
滑动窗口的滑动是以字节为单位的，发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小，发送方A根据B发送来的确认连接报文中标明的窗口的大小，来确定收到确认前的最大发送数据量，如果A接收到的B发来的确认报文中标明的窗口大小为0，则停止发送数据，直到收到不为0的确认报文，再继续发送。发送窗口表示在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已发送过的数据，在没有收到确认前都要暂时保留，以便超时重传时使用。

需要注意的一点是：使用TCP滑动窗口协议时，接收方不必确认每一个收到的分组，在TCP中，ACK确认是累积的，可以在接收到几个序号连续的报文段后只发送一个ACK确认报文，但累积等待的时间最长不能超过0.5秒，以防止发送端超时重传。

另外，要注意滑动窗口的三种变化：

1、窗口合拢。窗口左边沿向右边沿靠近，这种情况发生在数据被发送后收到确认时；

2、窗口张开。窗口右边沿向右移动，说明允许发送更多的数据，这种情况发生在另一端的接收进程从TCP接收缓存中读取了已经确认的数据时；

3、窗口收缩。窗口右边沿向左移动，一般很少发生，RFC也强烈不建议这么做，因为很可能会产生一些错误，比如一些数据已经发送出去了，又要收缩窗口，不让发送这些数据。

另外，窗口的左边沿是肯定不可能左移的，如果接收到一个指示窗口左边沿向左移动的ACK，则它被认为是一个重复ACK，并被丢弃。

总结以下几点：

1、发送方不必发送一个全窗口大小的数据，一次发送一部分即可。

2、窗口的大小可以减小，但是窗口的左边沿却不能向左移动。

3、接收方在发送一个ACK前不必等待窗口被填满。

4、窗口的大小是相对于确认序号的，收到确认后的窗口的左边沿从确认序号开始。

9.TCP的流量控制机制

一般来说，我们总是希望数据传输的更快一些，但如果发送方把数据发送的很快，而接收方来不及接收，这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。

对于成块数据流，TCP利用滑动窗口机制来实现流量的控制，对于交互数据流，TCP利用捎带ACK和Nagle算法来实现流量的控制。

下面就详细说下利用滑动窗口机制来实现流量控制的机制，先看下图：

我们假设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

我们考虑一种特殊情况，如果B在向A发送了零窗口报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段在传送过程中丢失了，A就一直等待B发送非零窗口的报文通知，而B一直等待A发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。

为了解决这个问题，TCP为每一个连接设有一个持续计时器(也叫坚持定时器)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），对方在收到探测报文段后，在对该报文段的确认洪给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方就重新设置持续计时器，如果窗口不为零，那么死锁的僵局就被打破了。

糊涂窗口综合症

设想一种情况，TCP接收方的缓存已满，而应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节长）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小时再发送给接收端。

10.TCP中的四大定时器

对于每个TCP连接，TCP一般要管理4个不同的定时器：重传定时器、坚持定时器、保活定时器、2MSL定时器。

重传定时器

很明显重传定时器是用来计算TCP报文段的超时重传时间的（至于超时重传时间的确定，这里涉及到一大堆的算法，书上有说，我这里不细谈了）。每发送一个报文段就会启动重传定时器，如果在定时器时间到后还没收到对该报文段的确认，就重传该报文段，并将重传定时器复位，重新计算；如果在规定时间内收到了对该报文段的确认，则撤销该报文段的重传定时器。

坚持定时器

上面已经提到了，主要是为了应付零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久，接收端的接收缓存又有了一些存储空间，于是接收端向发送端发送了一个非零窗口大小的报文段，然而这个报文段在传送过程中丢失了，发送端没有收到该报文段，就一直等待接收端发送非零窗口的报文通知，而接收端并不知道报文段丢失了，而是觉得已经告诉发送端了，就会一直等待发送端发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。

为了解决这个问题，TCP为每一个连接设有一个坚持定时器(也叫持续计数器)。只要TCP连接的一方收到对方的零窗口通知，就启动坚持定时器。若坚持定时器设置的时间到期，就发送一个零窗口控测报文段（该报文段只有一个字节的数据，它有一个序号，但该序号永远不需要确认，因此该序号可以持续重传），之后会出现以下三种情况：

1、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒，在此之后，每次收到零窗口通知，坚持计数器的值就定位60秒。

2、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口不为零，那么死锁的僵局就被打破了。

3、该探测报文发出后，会同时启动重传定时器，如果重传定时器的时间到期，还没有收到接收到发来的响应，则超时重传探测报文。

保活定时器

保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接，但后来客户端主机突然故障，则服务器就不能再收到客户端发来的数据了，而服务器肯定不能这样永久地等下去，保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据，就重新设置保活定时器，通常为2小时，如果2小时没有收到客户端的数据，服务端就发送一个探测报文，以后每隔75秒发送一次，如果连续发送10次探测报文段后仍没有收到客户端的响应，服务器就认为客户端出现了故障，就可以终止这个连接。

2MSL定时器

2MSL定时器测量一个连接处于TIME—WAIT状态的时间，通常为2MSL（报文段寿命的两倍）。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方，并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。

11.TCP的拥塞控制机制

计算机网络中的带宽、交换节点中的缓存和处理机等，都是网络的资源，在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况就叫做拥塞。

所谓拥塞控制，就是防止过多的数据注入到网络中，从而使网络中的路由器或链路不致过载。要注意用拥塞控制与流量控制的区别，拥塞控制是一个全局性的过程，涉及到所有的额主机、路由器，以及与降低网

拥塞控制的算法有：==慢开始、拥塞避免、快重传、快恢复==四种。

慢开始和拥塞避免

发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值（为了便于描述，后面的分析中假定对方给出的接收窗口足够大，这样将发送窗口等于拥塞窗口就可以了）。

慢开始算法的核心是从小到大逐渐增大发送窗口，也就是说，从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时，先把拥塞窗口设置为一个最大报文段MSS的数值，而在每收到对上一轮报文段（，每次加倍后的报文段的个数，可能不止一个报文段）的确认后，就把拥塞窗口的数值加倍。

为了防止拥塞窗口增长过大引起网络拥塞，还需要维护一个慢开始门限的状态变量，当拥塞窗口的值小于慢开始门限时，使用慢开始算法，一旦拥塞窗口的值大于慢开始门限的值，就改用拥塞避免算法。

拥塞避免算法的思路是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限设置为出现拥塞时发送窗口值的一般，但最小不能小于2个MSS值，而后把拥塞窗口的值重新设置为1个MSS，执行慢开始算法。

快重传和快恢复

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（重复发送对前面有序部分的确认），而不是等待自己发送数据时才进行稍待确认，也不是累积收到的报文发送累积确认，如果发送方连续收到三个重复确认（说明接收方连着收到三个失序报文），就应该立即重传对方未收到的报文段（有收到重复确认，说明后面的报文段都送达了，只有中间丢失的报文段没送达）。

快恢复算法与快重传算法配合使用，其过程有如下两个要点：

1、当发送方连续收到三个重复确认时，就把慢开始门限减半，这是为了预防网络发生拥塞。注意，接下来不执行慢开始算法。

2、由于发送方现在认为网络很很可能没有发生特别严重的阻塞（如果发生了严重阻塞的话，就不会一连有好几个报文段到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口的值不设为1个MSSS），而是把拥塞窗口的值设为慢开始门限减半后的值，而后开始执行拥塞避免算法，线性地增大拥塞窗口。

rto根据rtt计算

发送序号k 数据包 收到3次重复的k+1 ack确认

内容基本整理自：网络协议、网络协议入门、数据明文传输的安全问题

注：内容是从语雀上的学习笔记迁移过来的，有些参考来源已经无法追溯，侵权私删。

本文标签： 计算机网络 协议 简介 TCP http