一小时通关计算机网络（ 冲冲冲！！！）

计算机网络（ 冲冲冲！！！）"/>

一小时通关计算机网络（ 冲冲冲！！！）

通关计算机网络

• 第一关：因特网
• • 1.1 什么是因特网
  • • 从具体构成描述因特网
    • 从为应用程序提供服务的基础设施描述因特网
  • 1.2 网络的接入 （可跳过）
  • • 家庭接入 （DSL,电缆）
  • 1.3 网络核心（重要）
  • • 分组交换
    • 电路交换
    • 网络中的网络
  • 1.4 分组交换网中的 时延，丢包与 吞吐量
  • • 接下来我们来理解一下时延
    • 吞吐量
  • 1.5 协议层次与其服务模型
  • • 协议分层
    • OSI模型
• 第二关：应用层
• • 2.1 应用层协议原理
  • • 网络应用程序体系结构
    • 可供应用程序使用的运输服务
    • 因特网提供的实际运输服务
    • 应用层协议
  • 2.2 Web 与 HTTP
  • • HTTP 概况
    • HTTP 报文格式
    • 用户与服务器的交互：cookie
    • Web 缓存
  • 2.3 SMTP (simple Mail Transfer Protocal ，简单邮件传输协议)
  • 2.3 DNS: 因特网的目录服务
  • • DNS 提供的服务
    • DNS 工作机理概述
• 第三关： 运输层
• • 3.1 运输层服务详解
  • 3.2 多路复用与多路分解
  • 3.3 无连接传输： UDP
  • 3.4 可靠数据传输原理
  • 3.5 面向连接的运输： TCP
  • 3.7 TCP 拥塞控制

今天的网络发展无疑是人类历史上非常成功的设计系统，有数以亿级相连的计算机与移动设备，大家请跟随作者来快速闯关并见识那些处于网络的文明之光与领域知识。

第一关：因特网

因特网作为讨论计算机网络与其 协议的载体，我们通过它能够更好的见识网络的体系。

1.1 什么是因特网

1. 我们可以通过描述因特网的具体构成（构成因特网的硬件与软件组件）
2. 根据分布式应用提供服务的联网基础设施来描述因特网。

接下来我们就通过上面两点来走进 因特网的世界。

从具体构成描述因特网

部件介绍：

• 可以连接因特网的传统设备称为 主机 或 端系统 ， 它们容纳应用程序。
• 物理媒体（电缆吗，铜线，光纤）组成了 通信链路
• 当端系统向另一台端系统发送信息时，发送端系统将数据分段，并在端中加上首部字节，这样形成的信息叫 分组
• 能从入的通信链路接受到达的分组，且从出通信链路转发该分组 的设备叫 分组交换机（常见的是路由器与 链路层交换机）
• 端系统通过 通信链路 和 分组交换机 连接在一起

图：

可以说信息就是通过 从端系统（电脑）出，到通信链路（网线或光纤）进行运输，到分组交换机（转换口，也可以说是运输时需要进行信息转换与确认从 何出口出）。

部件如何接入因特网 与 协议的产生

• 端系统需要通过 因特网服务提供商（Internet Service Privider ，ISP）接入网络，其ISP自身就是由多个交换机于多端 通信链路组成的网络。
• 端系统，分组交换机和其他部件需要运行 一系列协议，这些协议控制着因特网信息的接受与发送（TCP，Transmission Control Protocal 传输层协议） 和 IP (Internet Protocal，网络协议) ，其中 IP 协议定义了在路由器和端系统之间发送和接受的分组格式。

图：

我们在实际的使用因特网，需要联系我们的本地因特网服务商（ISP） 购买并接入网络，之后我们通信使用一定的协议（遵守一定的约定）来控制我们的信息的收发。

从为应用程序提供服务的基础设施描述因特网

首先我们需要讲一个额外的术语：

• 我们使用的很多应用程序设计多个交换数据的端系统（比如：多台不同的服务器，或多台端系统为我们提供了数据的交换）我们称其 分布式应用程序

图：

之后我们需要想一想：

运行在一个端系统的程序是如何能令因特网向运行在另一台端系统的应用程序的软件发送消息的呢？

哈哈，其实这个我相信大家都听说过，其实是与因特网相连接的端系统呢提供了一个套接字接口（socket interface) 该接口规定了运行在一个端系统上的程序请求因特网基础设施向另一台端系统上的目的程序交付数据的方式。通过这种方式，我们就能进行通信。

图：

上节课我们提出协议，那么什么是真正的网络协议？

其实呢，协议（protocal）定义了在两个或多个通信实体之间交换的报文的格式和顺序，以及报文发送和/或接收一条报文或其他事件所采取的动作。

暗示： 掌握计算机网络领域知识的过程就是理解网络协议的构成， 原理和工作方式的过程。

1.2 网络的接入 （可跳过）

我们来理解一下接入网

• 接入网是指将端系统物理连接到其边缘路由器的网络。
• 边缘路由器是端系统到任何其他远程端系统的第一台路由器

你可以看看身边的第一台路由器，那就是你的边缘路由器，嘿嘿

家庭接入 （DSL,电缆）

这里我们主要讲一下这两种主要流行的类型： 数字用户线（DSP）和 电缆。

数字用户线（DSP）

• 通常我们从本地电话接入的电话公司（例如电信公司）来获得 DSL 因特网接入，这时我们的 ISP 网络提供商就是电信公司，DSL （双绞铜线）可以与本地的电话公司中心局的数字用户线接入复用器（DSLAM）交换数据，最后由本地中心局将数据推至因特网

这里我们讲一下DSL速率收费的问题，哈哈！！

DSL 定义了多个传输速率，而提供商呢提供分等级的服务，它们有意地限制了我们的 住宅速率，其中的 家庭与中心局的距离也影响了其 DSL 的传输速率。

电缆因特网接入利用了有线电视的基础设施，这里我们不讲其，我们讲一下光纤到户

1.3 网络核心（重要）

我们在接入网络后，就应该更向深入研究其 互联网端系统的分组交换机（路由器或链路层交换机）和链路所构成的网状网络。

通过网络链路和交换机移动数据有两种基本方法： 电路交换 和 分组交换

分组交换

当端系统向另一台端系统发送信息时，发送端系统将数据分段，并在端中加上首部字节，这样形成的信息叫 分组， 将分组通过通信链路和 分组交换机传送的过程叫 分组交换。

接下来我们介绍一下分组传输中的一些机制与问题

存储转发传输

在多数分组交换机（假定路由器）在链路的输入端使用 存储转发传输 机制。

它指的是 交换机能够开始向输出链路传输该分组的第一个比特之前，必须接受到整个分组，仅当接收完该分组的所有比特，才嗯那个向链路输出。

排队时延与分组丢失

每台分组交换机有多条链路相连， 对于每条相连接的链路， 分组交换机均有一个输出缓存，也叫输出队列
它，用于存储路由器准备发往那条链路的分组。

• 到达该输出队列的分组所在的链路如果正忙于传输其他分组，该分组必须在输出队列等待，因此，存在了 排队时延。
• 由于缓存（输出队列）是有限的，一个到达的分组可能发现该 输出队列 已经被排队等待传输的分组充满了，在此情况下，到达的分组或已经在排队的分组之一被丢弃，称之为 丢包

那么，被传输的分组是如何准确地到达目的地的呢？接下来我们来讲解一下其原理。

转发表与路由选择协议

在因特网中，每个端系统都具有一个称为 ip 的地址。

当源主机向目的端系统发送一个分组时，源在该分组的首部填入了其目的地的 Ip 地址，就像邮政地址一样，该地址是一种等级结构。

• 当一个分组道道网络路由器时，路由器会检查该分组的目的地址的一部分，通过这一部分并向一台相邻路由器转发该分组，其原理是 转发表 用于将目的地址映射成为 输出链路，供路由选择并将该分组导向该输出链路。

这些转发表是我们手工设置的吗？

其实并不是，因特网具有一个特殊的路由选择协议，用于自动设置这些转发表，原理是路由选择协议决定从每台路由器到每个目的地的最短路径，使用这些最短路径结果来配置路由器中的转发表。

电路交换

在电路交换网络中，端系统通信会话期间，预留了端系统间沿路径通信所需要的资源（缓存，与链路传输速率）。

预留，代表了预定，就像去餐厅吃饭预定一样，无须等待，来了就就餐。可以说通信期间，可以保证实时安全，但避免不了资源的占领与等待（预定好了饭，但是很长时间都不来就餐）

这里我们来对比一下 分组交换与电路交换 （连科学家们都在争辩，哈哈）

首先分组交换的性能优于电路交换的性能，在多个数据流之间共享链路传输速率的两种形式的关键差异在于：

• 电路交换不考虑需求，而预先分配了传输链路的使用，这使得已经分配而并不需要的链路时间上得不到利用，
• 分组交换按需求分配链路使用， 链路传输能力将在所有需要在链路上传输分组的用户之间逐渐分组地被共享。

目前我们的社会都在朝向分组交换方向发展。

网络中的网络

其实呢，在我们今天，因特网是一个网络的网络，其结构复杂，由高层 ISP（网络提供商） 与 底层 ISP 组成，其跨越大洋和大洲， 我们用到的内容都是由 底层ISP 提供，而 底层 ISP 的内容是 较高层 ISP 提供，高层与高层，低层与低层，高层与低层彼此之间相互联，（互联网也是顾名思义吧）

1.4 分组交换网中的 时延，丢包与 吞吐量

前面我们讲到未来分组交换网是趋势，可通过分组交换方式的因特网能够达到任意两个端之间信息能随心所欲地瞬时移动数据而没有数据丢失，是极高的目标。

计算机网络与现实物理定律碰撞，其必定会产生 时延，丢包，限制吞吐量的问题（就像运输货物时出现的问题，收费站等待，货物散落，运输速度限制），处理这些问题就显得极为重要与令人痴迷。

接下来我们来理解一下时延

分组在从一个节点（分组交换机）沿着这条路到后序的节点（分组交换机），会经历不同类型的时延，包含
节点处理时延（nodal processing delay）， 排队时延（queuing delay），传输时延（transmission delay）和传播时延 （propagation delay），累加起来就是总时延。

图示：

• 处理时延：

1. 检查分组首部和决定该分组导向何处所需的时间
2. 检查比特级别的差错所需时间

• 排队时延

一个特定分组的排队时延长度决定于先期到达的正在排队等待向链路传输的分组数量，如果队列是空的，且没有其他分组正在传输，则排队时延为 0

• 传输时延

传输时延是路由器推出分组所需要的时间， 与分组长度和链路传输速率的正比有关，与路由器（分组交换机）举例无关

• 传播时延

从链路起点到下一个路由器（节点或分组交换机）所需的时间是传播时延，与两台路由器之间的距离有关。

可以说，我们从当前电脑到 另一台目的电脑所需的时延是（忽略拥塞问题，即排队时延） N（N个分组交换机）（处理时延+ 传输时延+传播时延）

接下来我们来讲一下除了时延之外最重要的性能测度（端到端吞吐量）

吞吐量

假定主机A 到B传输一个大文件。

• 在任何时间瞬时的瞬时吞吐量就是 B 接收到文件的速率
• 传输文件的大小除以时间是 平均吞吐量
• 对于多链路网络，其吞吐量是 链路速率的最小值，假定 路由器前后两条链路，链路速率分别是 Rc 与 R d，则吞吐量是 min(Rc, Rd)

从上面看出，吞吐量取决于数据流过的链路的传输速率，其吞吐量近似看成沿着源和目的地之间路径的最小传输速率

1.5 协议层次与其服务模型

由于计算机网络体系是十分复杂的，但请不要怀疑能不能构建其结构，因为接下来我们将进入其 前辈们总结的协议层次与服务模型。

协议分层

为了给网络协议的设计提供一个结构， 网络设计者以 分层的方式组织协议以及实现这些协议的网络硬件与软件。

各层的所有协议称为 协议栈。因特网的协议栈由 5个 方面进行组成，我们会在一下一一简要概述，后面我们会继续详细通过这些知识。

• 应用层： 是网络应用程序与应用层协议存在的地方， 协议有（HTTP），(SMTP),FTP ，将地址转换为域名这样的操作是借助于 特定的 应用层协议域名系统DNS完成的。

应用层协议分布在多个端系统商，而一个端系统使用协议与另一个系统之间应用程序交换信息分组，我们将这种位于其应用层商的信息分组称为 报文。

• 运输层： 运输层在应用程序端点之间传送应用层报文，常见的运输协议是 TCP/IP，这些协议会将报文分割为 短报文（报文段）进行传输。

• 网络层： 负责将称为 数据报 的网络层分组从一台主机移动到另一个主机，其运输层协议会向网络层递交运输层报文段与目的地址。
  其包含了 网际协议 IP，定义了在数据报中各个字段以及端系统和路由器如何作用于这些字段。
  也定义了路由选择协议，它根据路由将数据报从源传输到目的地。

• 链路层： 网络层将数据包下传给链路层，链路层沿着路将数据包传递给下一个节点（交换机），在下一个节点，链路层也会将数据报上传给网络层。

• 物理层： 物理层的任务是从该帧中的一个一个比特从一个节点移动到下一个节点。

OSI模型

国际标准化组织 （ISO） 提出计算机网络围绕7层组织，称其开放系统互连模型

七层模型是： 应用层，表示层，会话层，运输层，网络层，数据链路层于物理层。

比因特网新添加了表示层与会话层。

表示层：作用是使得通信的应用程序能够解释交换数据的含义，包括数据压缩和加密与解释。
会话层： 提供了数据交换的定界和同步功能，包括了简历检查点与恢复方案的方法。

封装的概念，嘿嘿

• 应用层报文和运输层首部信息构成了 运输层报文段 （M -> (Ht, M)）.因此运输层报文段封装了应用层报文，大概封装信息： 允许接收端运输层向上向适当的应用程序交付报文的信息；差错检测位信息。该信息让接收方判断报文中的比特在途中是否被改变。
• 运输层向网络层传递该报文段，网络层增加了如源和目的端系统地址等网络层首部信息，生产了网络层数据报。
• 将该数据报传递给链路层，链路层也增加了其链路首信息生成 链路层帧。

一个分组具有两种类型的字段： 首部字段与 有效载荷字段（来自上一个层）

封装的过程能够比前面描述的更加复杂，一个大报文可能被划分多个运输层报文段，在接收端，必须从其连续的数据报中重构这样一个报文段。

第二关：应用层

网络应用是计算机网络存在的证明， 从现在开始我们来学习 因特网的最顶层，也是与我们接触最多的一层，
大致我们需要学习的部分是 定义关键的应用层概念，包括 应用程序所需要的 网络服务，客户和服务器，进程和运输层接口。

2.1 应用层协议原理

网络应用程序体系结构

目前的主流体系结构：（c/s）客户端 -服务器结构与对等（p2p）体系结构

cs : 一个总是运行的主机服务器，服务于其他来自客户的主机请求
p2p：主机对之间直接通信，主机对被称为对等方。

进程通信

构建网络应用程序前，我们需要对运行在多个端系统商的程序是如何互相通信情况有一个基本了解。

• 进行通信的其实是进程而非程序，一个进程可以被认为是运行在端系统中的一个程序，两个不同端系统商的进程通过跨越计算机网络交换报文而互相通信。

进程寻址

一般情况下，一台主机上 的进程为了向另一台主机上运行的进程发送分组，要定义两种信息：

1. 主机的地址 （IP地址实现， 是一个32比特的量且能够唯一地标识该主机）
2. 在目的主机中指定接受进程的标识符 （端口号标识主机的指定进程）

图：

可供应用程序使用的运输服务

我们知道套接字是应用程序和运输层协议之间的接口，在发送端的应用程序将报文推向套接字，在套接字的另一端，运输层协议负责从接受进程的套接字得到该报文。

这里我们思考一下，运输层协议能够为调用它的应用程序提供上面服务呢？

其实有四种：

1. 可靠的数据传输

运输层协议能够潜在地向应用程序提供一个重要服务是进程到进程的可靠数据传输，发送进程只需要将数据传递给套接字，就可以完全相信其数据能够无差别地到达接收进程。

2. 吞吐量

运输层协议能够以某种特定的速率提供确保的可用吞吐量，具有吞吐量要求的应用程序被称为 带宽敏感的应用，我称其为 “抢占网速的大型软件”。

3. 定时

运输层协议也能提供定时保证。

4. 安全性
   运输层协议能够为应用程序提供一种或多种安全性服务，加密解密过程，数据完整性与端点鉴别手段。

因特网提供的实际运输服务

因特网考虑到计算机网络运输服务的需求，提供了两种运输层协议 ，UDP 与 TCP

由于协议为调用它们的应用程序提供了不同的服务集合，我们需要在选择时进行良好冷静的判断

1. TCP 服务

TCP 服务模型包括面向连接的服务，与 可靠数据传输服务。

• 面向连接的服务：

准备： 客户端服务器进行互相交换运输层控制信息，为大量分组的到来做准备
全双工： 连接双方的进程可用在此连接上同时进行报文手法，当应用程序结束报文发送，必须拆除该连接。

• 可靠的数据传送服务：通信的进程能够依靠 TCP，无差别，按适当顺序交付所有发送的数据。

应用程序的一端将字节流传入套接字中时，能够依靠 TCP 将相同的字节流交付给接收方的套接字，没有字节的丢失与 余。

Tcp协议也提供了拥塞控制机制，当发送与接受方网络出现拥塞时，TCP的拥塞机制会抑制发送进程。

TCP 的安全性: tcp的加强版（SSL，安全套接字层），能够做到 TCP 做到的一切，还提供了加密，数据完整性与端点鉴别。

2. UDP 服务

UDP 是一种不提供不必要服务的轻量级运输协议。

• 无连接，无握手过程。
• 不可靠的数据传输服务，UDP 并不保证该报文将到达接收方进程，到达的报文也不能被保证是 顺序或完整。
• 没有拥塞控制机制，UDP 发送端以它选定的任何速率向其下层注入数据。

应用层协议

我们从以上大致了解了如何实现网络进程间相互通信，但如何构造这些报文，报文中的字段含义是什么，进程什么时候发哦是那个这些报文？

这些问题苦恼着我们，其实呢，这些问题都能够在应用层协议中看到。

应用层协议定义了运行在不同端系统上的应用程序如何相互传递报文，其定义了：

• 交换的报文类型， 例如请求报文与响应报文
• 各种报文类型的语法，报文中的各个字段与其如何描述
• 字段的语义，字段中的信息含义
• 确定进程何时如何发送报文，对报文进行响应的规则。

也可以说应用层协议定义了应用程序间的消息逻辑规则，其应用层协议大多都是 由 RFC 文档定义。

接下来我们讲解一些比较出名的 应用层协议，如 http 等等

2.2 Web 与 HTTP

Web 是一个引起世界公众关注的因特网应用，Web使得信息能够满足人们按需操作，是十分方便的知识海洋阅览器。

HTTP 概况

Web 应用 使用的应用层协议是 HTTP （HyperText Transfer Protocal ），是 WEB 的核心。

接下来我们来了解一下 HTTP 在WEB 的实际作用：

• HTTP 定义了 WEB 客户向 WEB 服务器请求 WEB 页面的方式，以及服务器向客户传送 WEB 页面的方式。

图：

HTTP 的工作原理：

HTTP 使用 TCP 作为它的支撑传输协议（而非 UDP）

• HTTP 客户先发送一个与服务器的 TCP 连接，一旦建立起连接，浏览器与服务器进程就能通过套接字接口访问TCP。 这就好比 客户端套接字接口是 客户端进程与 TCP 连接之间的门，在服务器端的套接字接口则是服务器进程与TCP连接之间的门

• 一旦客户或服务器向其套接字接口发送了报文，这就表明 报文将脱离其程序控制进入到 TCP 的控制

• TCP 为 HTTP 提供了可靠数据传输服务，HTTP无须担心数据丢失或 TCP 从网络的数据丢失和乱序故障恢复的这些事情，这样的分层管理优点也是很大的。

• HTTP 是一个无状态协议， 服务器并不存储关于客户的任何信息，当客户发起两次请求对象时，服务器会重复发送，当你在网页上多次请求下载软件时，会下载两次！

HTTP 的非持续连接与持续连接

在我们的因特网应用程序中，客户端 与服务器在长时间内通信，其中客户发送一系列请求并且服务器对每个请求进行响应，这一系列请求可以以规则的间隔周期地或是间断一个个发出。

由于客户服务器的交互方式是TCP 方式进行的，应用程序需要做出一个决定： 即每一个请求是经一个单独的TCP进行发送（非持续性连接），还是 所有请求都响应经相同的TCP连接（持续性连接）

默认情况下： HTTP 采用 持续性连接

对比非持续性连接与持续性连接

非持续性连接的缺点十分明显：

• 每个请求的对象维护一个全新连接，共需要 三次握手与数据交换，至少 两个 RTT加上服务器传输 HTML 文件的时间，并且由于多个TCP连接带来的 服务器压力也很大（客户端与服务器都要分配其 TCP 缓冲区和保持 TCP 变量）

HTTP 报文格式

HTTP 报文有两种: 请求报文与响应报文

请求报文

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: Close
User-agent: Mozilla/5.0
Accept-language: fr

我们来解释一下上面的报文意思：

首先呢，请求报文的规则是至少为 一行，HTTP请求报文的第一行叫 请求行，其后的所有行叫 首部行。

• 请求行有 3个字段： 方法字段/URL字段/HTTP 版本字段，方法字段包括 （GET,POST,HEAD,PUT,DELETE）,
  URL 带有请求对象的标识，HTTP 版本字段是 自己解释的

• 首部行中 ：
  Host 代表了对象所在的主机，
  Connect: close 告诉服务器当发送完请求的对象后就关闭这条连接。
  User-agent: 用来指明用户代理，即向服务器发送请求的浏览器的类型。
  Accept-language：代表了用户想得到该对象的语法版本。

响应报文

HTTP/1.1  200 OK
Connection：  close
Data: Tue, 18 AUG 2015  15.44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015  15:11:03  GMT
Content-Length: 6821
Content-Type: text/html(data data)

响应报文呢，由3部分构成： 初始状态行，6个首部行， 实体体

• 初始状态行： HTTP 版本， 状态码与短语，其指示了请求的结果。

1. 200 OK : 请求成功，信息在返回的响应报文中。
2. 301 Moved Permanently： 请求的对象已经已经被移除了，新的URL 定义在相应报文的 Location，首部行中，客户软件将自动获取新 URL
3. 400 Bad Request： 一个通用错差代码，指示该请求不能被服务器理解
4. 404 Not Found： 被请求的文档不在服务器上
5. 505 Htttp Version Not Supported：服务器不支持请求报文使用 HTTP 协议版本。

• 首部行：

1. Connect: close 发送完将关闭该 TCP 连接
2. Date： 服务器产生并发送该响应报文而的日期与时间
3. Server： 指示服务器的类型，类似客户端的 user-agent
4. Last-Modified: 指示对象创建或最后修改的日期与时间
5. Content-Length：被发送对象中的字节数
6. Content-Type：实体中的对象

用户与服务器的交互：cookie

cookie 其实是非常好理解的，是指用户信息的索引缓存，也可以说是服务器用于标识一个用户的工具。但是也造成了用户信息泄露的问题，国家都很在意这些我们这些网民的 隐私安全。

Cookie技术一般有 4个组件：

1. HTTP 响应报文中的一个 Cookie 首部行
2. 在 HTTP 请求报文中的 一个cookie首部行
3. 用户端系统保留一个 cookie文件，由用户的浏览器进行管理
4. 位于 Web站点的一个后端数据库。

当我们的请求网页的过程，WEB站点会产生唯一一个识别码，并以此作为索引在后端数据库产生一个表现。

图：

Web 缓存

WEB 缓冲器 也叫 代理服务器，就像我们去通过百度去访问其他网站一样，百度平台就是我们的 代理服务器。

使用代理服务器的好处：

• 大大减小服务器对客户端的响应时间，对客户是非常友好的。
• 大大降低器因特网 web 流量，改善了所有应用的性能。

通过内容分发网络（Content Distrubution Network，CDN），WEB 缓存器正在因特网上发挥着越来越重要的作用，CDN公司在因特网安装了很多地理上分散的缓存器，因而使大量流量实现了本地化。

2.3 SMTP (simple Mail Transfer Protocal ，简单邮件传输协议)

这里对于邮件协议不再进行过多描述，我们转向更实用的 应用层协议（DNS）

2.3 DNS: 因特网的目录服务

DNS 为什么被提出，这其实涉及了一些很常见的有趣的问题。

因为端系统分组传输是需要 IP地址与端口的，但是 IP 地址是数字格式，是非常难以牢记的，比如 人们很乐意接受（www.baidu )而不乐意去接受（192.168.2.1…）数字IP ，所以域名是非常重要的，但是通信是需要 IP 的，域名向IP 解析这一需求促使了 DNS 服务的出现。

DNS 提供的服务

DNS :

• 由分层的DNS服务器实现的分布式数据库
• 一个使得主机能够查询分布式数据库的应用层协议（DNS协议运行在 UDP 之上，使用 53端口）

DNS 工作机理概述

假设运行在用户主机上的某些应用程序（web 应用) 需要将主机转换为 IP 地址

• 这些程序调用 DNS 的客户端，并指出需要被转换的主机名，
• 用户主机上的 DNS 接受到后，向网络中发送 一个 DNS 查询报文。所有 DNS请求和回答报文均使用 UDP数据经端口 53 发送
• 经过若干秒时延后，用户主机上的 DNS 接收到一个提供所希望映射的 DNS 回答报文，这个映射结果再被传递到调用 DNS 的应用程序。

大家看到，看似 dns 只是作为一个提供简单和直接的转换服务的黑盒子，但是实现这个黑盒子是十分复杂的，它由分布于全球的大量 DNS 服务器以及定义了 DNS 服务器与查询主机通讯方式的应用层协议组成。

DNS 缓存

由于解析域名是非常消耗时间的，为了改善时延性能并改善在 因特网到处传输的 DNS 报文数量，引入了DNS 缓存，

第三关： 运输层

作为应用层的下层协议，运输层为运行在不同主机上的应用进程提供直接的通信服务有至关重要的作用。

作为笔者：我将 着重关注 的是 TCP 与 UDP 运输协议

通过以下方面来讲述运输层：

1. 运输层与网络层的关系
2. 原理学习，运输层协议的技术是如何体现的（如何可靠的通信）
3. 控制运输层实体的传输速率以避免 网络拥塞，以及从拥塞中恢复。

3.1 运输层服务详解

• 运输层协议是为运行在不同主机上的应用程序之间提供了 逻辑通信
• 运输层协议是在端系统中而不是在路由器中实现的

运输层的工作解释：

在发送端，运输层将从发送应用程序进程接收到的报文转换成运输层分组（运输层报文段），网络层将器封装为网络层分组（数据报）
并向目的地发送，我们之前提及的 封装的概念

注意: 网络路由器仅仅作用于数据报的网络层字段；它们不检查封装在该数据报的运输层报文段的字段。

在接收端，网络层从数据报中提取运输层报文段，并将该报文段向上交给运输层。运输层则处理接受到的报文段，使得该报文段中的数据为接受应用进程使用。

运输层和网络层的关系:

网络层提供了对主机之间的逻辑通信，运输层为运行在不同主机上的进程提供了逻辑通信。

一般情况下，我们想到主机之间的逻辑通信不通或有问题出现，那么当然应用程序之间的通信也一定不会正常。推理到网络层与运输层上，即：

运输协议能提供的服务受底层网络层协议的服务模型限制，如果网络层协议不能为主机之间发送的运输层报文段提供时延或带宽保证的话，运输层协议也就无法向进程之间发送的应用程序报文提供时延或带宽保证。

因特网运输层概述:

因特网为应用层提供了两种截然不同的可用运输层协议： UDP（User-Datagram- protocal 用户数据报协议），TCP（Transfer-Control-Protocal : 传输控制协议）

UDP： 为应用程序提供了 不可靠，无连接的服务
TCP：为应用程序提供了可靠，面向连接的服务。

UDP 与 TCP 的最基本的任务是： 将两个端系统间的 IP 的交付服务扩展为运行在端系统上的应用程序进程之间的交付服务，其也被称为运输层的多路复用和多路分解。

UDP 提供的服务： 与进程到进程的数据交付与数据的差错检查两种服务。
TCP 提供的服务： 与进程到进程的数据交付与数据的差错检查，提供了 额外地 可靠数据传输与拥塞控制服务。

注意:

• 一般我们开发时生成套接字 时必须指定其协议是 UDP or TCP
• TCP运输层分组称为报文段，UDP 称为数据报，同时将网络层分组也称为数据报，这里我们将 TCP 和 UDP 的分组统称 报文段，数据报名称保留给网络层分组不容易混淆。

3.2 多路复用与多路分解

我们知道： 一个进程有一个或多个套接字，它相当于从网络向进程传递数据和从进程向网络传递数据的门户，因此呢，运输层实际上并没有将数据直接给进程，而是递交给了中间的套接字。

现在有一个问题： 接受主机怎么样将一个到达的运输层报文段定向到适当的套接字？

• 其实呢, 运输层的报文段都具有几个字段（目的端口号），在接收端，运输层检查这些字段，标识出接受套接字，进而将报文段定向到套接字上。

图：

• 将运输层报文段中的数据交付到正确套接字的工作是 多路分解
• 在源主机从不同套接字收集数据块，并为每个数据块封装首部信息生成报文段，然后将报文段递交到网络层，这些工作称为多路复用。

运输层多路复用的要求：

• 套接字有唯一的标识符 （源端口）
• 每个报文段有特殊字段来指示该报文段所交付的套接字 （目的端口）

端口是 16 比特的数，大小是 0-65535 之间，0-1023 范围的端口号称为 周知端口号，是受限制的，当我们开发一个应用程序，需要为其分配一个端口号。

运输层分解服务的实现：

在主机上的每个套接字能够分解一个端口号，当报文段到达主机时，运输层检查报文段中的目的端口号，并将其定向到响应的套接字，然后报文段的数据通过套接字进入相连接的进程。

无连接的多路复用与多路分解

上述即可

注意：

UDP套接字是一个二元组全面标识的，二元组包含一个目的 IP 与 目的端口。

回发消息时，接受信息的一方会将其提取的源端口号作为目的端口。向客户发送新报文段。

面向连接的多路复用与多路分解

TCP 与 UDP套接字 的差别是 TCP套接字是 四元组（源IP/端口，目的IP/端口）标识的, 当TCP报文段到达一个主机时，该主机使用 四个值来定向分解到相应的套接字。

3.3 无连接传输： UDP

UDP 是无连接，不可靠的运输层协议。
UDP 可以理解为 对网络层协议增加了一点点多路复用与多路分解服务而已。

UDP功能概述：

UDP 做了运输协议能够做的最少工作，UDP 从应用进程得到数据，附加上用于 多路复用，分解服务的源和目的端口号字段，以及两个其他的小字段，然后将形成的报文段递交给网络层，网络层将运输层报文段封装到一个IP数据报中，然后尽力而为地将尝试把其数据报交付给接受主机，如果报文段到达接受主机，UDP 使用目的端口号将其数据交付给正确的应用进程。

UDP 的特点

• 关于放松什么数据与何时发送的应用层控制更为精细。
• 无须连接创建
• 无连接状态
• 分组首部开销小。

UDP 对于数据传递是非常直接的，只要应用传递给UDP，UDP就会将数据打包立即传递给网络层。且无须对目的主机进行建立连接，因此并没有连接状态（不用提供额外的维护连接状态的字段），其分组的 UDP 首部字段也是较少的，为 8字节，TCP则20字节。

UDP 报文段结构：

UDP首部有4个字段，各占两个字节。

图：

• 通过端口号（源端口，目的端口）能使得目的主机将应用数据交给运行在目的端系统中的相应进程（也可以说交付给套接字。。）。
• 长度字段指示了UDP报文段中的字节数（首部加数据）
• 接收方使用检验和检查在该报文段是否出现了差错

UDP 检验和

UDP 检验和提供了差错检测功能，检验和用于确定当 UDP报文段从源到目的地移动时，其中的比特是否发生了变化。

具体实现：

• 发送方的 UDP 对报文段中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷，得到的结果被放在 UDP 报文段中的检验和字段。

3.4 可靠数据传输原理

可靠数据传输的框架：

数据可以通过一条可靠的信道进行传输。借助于可靠信道，传输数据比特不会受到损坏或丢失，而且所有数据都是按照其发送顺序进行交付。

//TODO

3.5 面向连接的运输： TCP

TCP 是因特网运输的面向连接的可靠运输协议，TCP 依赖于 （差错检测，重传，累计确认，定时器 以及用于序号和确认号的首部字段）完成可靠数据传输。

TCP 连接

端到端的应用进程使用TCP通信前需要进行握手，即它们必须先互发 预备报文段，以建立确保数据传输的参数。

• TCP 连接是逻辑连接，共同状态仅仅保留在通信端系统的 TCP 程序中
• TCP 提供全双工服务，即数据传输是对于两个进程之间是相互的，且是点对点的，即在单个发送方于单个接收方的连接

客户进程通过套接字传递数据流，一旦通过套接字，数据就交与运行的 TCP 进行控制。

• TCP 会将客户进程的数据引导到 连接的 发送缓存中，接下来TCP会从发送缓存中取出一块数据，并将其递交到网络层，其取出的最大数据量受限于 最大报文段长度（MSS： Maximum Segment Size） ， MSS 根据最初确定的由本地发送主机发送的最大链路层帧长度（最大传输单元）设置，（MSS保证大于一个 TCP/IP 首部长度 40字节）
• 同时接收方也会提供 接受缓存

TCP 连接的组成由：

• 一台主机上的缓存，变量，进程连接的套接字
• 另一台主机上的缓存，变量，进程连接的套接字

TCP 报文段结构

• 源端口号于目的端口：用于多路复用，分解来自或送到上层应用的数据 共4字节
• 检验和字段 2字节
• 4 字节的序号字段和 4字节的确认号字段，用于发送方于接收方来实现可靠数据传输服务
• 2 字节的接受窗口字段，用于流量控制，用于指示接收方愿意接收的字节数量
• 0.5 字节的 首部长度字段，标识了 TCP 首部长度
• 可选于变长的选项字段
• 6 比特的标志字段，

1. ACK 用于指示确认字段中的值是是有效的，即该报文段包括一个对已被成功接收报文段的确认。
2. RST,SYN,FIN 比特用于连接与拆除
3. PSH 指示接收方应立即将数据交给上层
4. URG 用于指示报文段存在着被欸发送端的上层实体置为 “紧急”的数据

• 2字节的紧急数据指针字段，当紧急数据存在并给出指向紧急数据尾指针时，TCP必须通知接受端的杀虐那个实体

序号与确认号

TCP 将数据看成一个 无结构，有序的字节流

报文段的
序号（sequence nuber for segment） ：是该报文段首字节的字节流编号
确认号： 主机 A填充进报文段的确认号是主机 A 期望从主机 B 收到的下一字节的序号。

TCP 连接管理

这节我们主要来观察如何建立和拆除一条 TCP 连接

建立一条 TCP 连接：

• 第一步：客户端的TCP 首先向服务器端的 TCP 发送一个 SYN 报文段(不包含应用层数据，SYN 位被置为1， 客户端并设置一个 初始序号（client_isn）,放置于 TCP SYN报文段中的序号字段中，该报文段会被封装在 IP 数据报中，发送到服务器

连接的意思：我想与你建立连接，并发送了一个 SYN分组信息给你

• 第二步： 服务器端收到该报文段，提取出其 TCP,SYN 报文段，为该 TCP 连接分配 TCP缓存和变量，并向该客户 TCP 发送允许连接的报文段（不包含应用层数据），报文段包括以下信息： （SYN被置为1， TCP报文段首部的确认号字段被置为 client_isn +1, 最后服务器选择自己的初始序号 server_isn,并将其放置到 TCP 报文段首部的序号字段中）

连接的意思：我受到了你发起建立连接的 SYN分组，该分组带有你的 client_isbn.我同意连接，我自己的初始序号是 server_isn,其允许连接的报文段是 SYNACK报文段

• 第三步：受到 SYNACK报文段后，客户也为连接分配了 缓存与变量，客户端向服务器发送一个对服务器允许连接的报文段进行确认的报文段ACK报文段（ack = server_isn +1 ），此时连接建立，且发送的包中 SYN 也被置为了 0，第三个阶段可以在报文段负载中携带客户到服务器的数据。

总结以下：

第一次： 客户端向服务器发送 SYN 报文段， （SYN= 1, seq = client_isb）
第二次：服务器向客户端发送 SYNACK报文段 （SYN =1 ,ACK =1 , seq = server_isn, ack = client_isn + 1）
第三次：客户端向服务器发送 ACK报文段 （SYN = 0 ,ACK = 1, seq = client_isn +1 , ack = server_isn +1 ）

SYN洪泛攻击

如果第三次握手，客户端不发送 ACK来完成该三次握手，那么大概在 一分多钟发服务器会自动终止该半开连接并回收资源。

这时给了 Dos 攻击（SYN 洪泛攻击）提供了环境。攻击者凭借着发送大量的 TCP SYN洪泛攻击，而不完成第三次握手的步骤，这就会造成服务器不断地为这些半开连接分配资源，但从未使用，导致服务器的连接资源资源被消耗殆尽。

防御技术： SYN cookie

当服务器接受到一个SYN报文段，服务器由于不清楚来源（是否是洪泛攻击），服务器会生成一个 初始 TCP 序列号，使用源与目的地址与端口号以及仅有服务器知道的秘密数制作的 复杂函数制作（cookie）

如果客户不发来 ACK，那么对于服务器不会产生危害，因为服务器没有为其分配资源，如果发来 ACK，则进行验证，并直接生成一个具有套接字的全开连接。

为什么需要三次握手，二次不行吗？

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。

失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费，使用第三次握手客户端就能对其失效的数据包进行确认并发向服务器，能保证客户端断开连接后，服务器与客户端都会有一个安全的释放。

为什么需要初始序号？

拆开一条TCP连接：四次挥手

（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

标记位为FIN，表示“请求释放连接“；
序号为Seq=U；
随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
序号为Seq=V；
确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
随后服务器端开始准备释放服务器端到客户端方向上的连接。
客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
序号为Seq=W；
确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。
**随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。**并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。
随后客户端开始在TIME-WAIT阶段等待2MSL，这使得 客户端重传最后的确认报文。

为什么建立连接需要三次握手，而断开连接需要四次握手？

因为每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包。

在建立连接时，服务器可以把SYN和ACK放在一个包中发送。

但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接。

因此很多时候FIN和ACK需要在两个数据包中发送，因此需要四次握手

为什么要客户端要等待2MSL呢？

服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。

客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

客户端与服务器状态变化图：

3.7 TCP 拥塞控制

TCP 所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能像连接发送流量的速率。

这就很有意思了，这句话我听着都蒙圈，里面大概有三个问腿；

• 发送方如何感知网络拥塞程度？
• TCP发送方如何限制向其连接发送流量的速率呢？
• 发送方感到端到端的拥塞，采用何种算法来改变其发送速率。

TCP 如何限制向其连接发送流量？

• 运行在发送方的TCP 拥塞控制机制跟踪一个额外的变量 ，拥塞窗口（congestion window），它对一个 TCP 发送方能向网络发送流量的速率进行了限制。

往返时间不变，限制其 数据量，导致速率下降。

TCP发送方如何限制向其连接发送流量的速率呢？

当出现过量的拥塞时，在沿着这一条路径上的一台路由器缓存会溢出，引起一个数据报（包含一个TCP 报文段）丢弃。丢弃的数据报会引起发送方的丢包事件（超时，或收到 3 个 冗余ACK），这时发送方就会认为在发送方到接收方的路径上出现了拥塞的指示。

TCP 发送方如何使用算法来控制 拥塞窗口 的大小呢？

1. 慢启动 ：TCP 发送速率起始慢，慢启动阶段指数增长（MSS，2MSS，4MSS）
2. 拥塞避免 ： 增进 1 个 MSS
3. 快速恢复 ; 窗口直接恢复为 1MSS

每个RTT内 拥塞窗口线性增加 1 MSS，然后出现冗余ACK事件时 拥塞窗口减半，TCP 拥塞控制位 加性增，乘性减