计算机网络自顶向下方法第二章笔记

前言：因之前做的笔记很多知识粗略带过，期末考又以概念题居多，现来补充一些细节。本文参考自很多文章、课本、PPT等（其实仔细观察你会发现网上很多文字甚至图片都是一致的），如有雷同，真的不巧合，但是本人保证本人的笔记只是给自己复习用的（抱拳）

计算机网络感觉真的很像高中学的生物，虽然是理科，但是学科里有诸多概念，诸多细节，需要大家认真理解和记忆才行，这种科目一般得很上心才能做到融会贯通。
我有个朋友告诉我，就是遇到每个概念的时候，像对待文科那样，明白
①、是什么（这个概念什么意思，即含义）
②、为什么（这个概念为什么被提出，即能解决什么问题）
③、怎么做（这个概念是怎么解决刚才提出的问题的）
如此即可，说到容易，做到难，共勉！

二、应用层

2.1 应用层协议原理

应用层协议只能运行在端系统，这种限制促进了应用程序的开发，即开发不用考虑底层网络核心的实现。

2.1.1 网络应用程序体系结构

客户机-服务器体系结构（CS）

• 最常见的体系结构，特点是“一对多，一台服务器对应多个客户机”，
• 服务器主机总是打开着的，接受请求，提供响应给其他客户机主机。
• 服务器是处理所有逻辑的中心，具有固定的 IP 地址。
• 因上一条，所以客户机之间不直接通信，要通信必须经过服务器。
• 基础设施密集。虽然客户机/服务器体系结构的特征是“一对多”，但是服务器却并不总是一台，因为有的时候要处理海量的客户机的请求， 一台服务器很快就会不堪重负，所以这个时候常用服务器集群技术（server clustering）创建强大的虚拟服务器。所以此时这里“一对多”的一要理解为一组服务器组成的“一”个整体的意思
• 应用：WEB，FTP，电子邮件，Telnet

P2P体系结构（对等结构）

• 应用程序在间断的主机对之间进行直接通信，这些主机对被称为对等方。
• 特点：客户机间的直接通信使得P2P有了强大的自扩展性（self-calability），比如下载文件时接收到文件的主机又可以直接把文件上载给其他的主机，因此对基础设施服务器依赖较小，并且可上载该文件的主机的数量是指数递增的，系统的服务能力只会越来越强。
• 应用：文件分发，因特网电话，文件搜索

2.1.2 进程通信

客户和服务器进程

• 网络应用程序由成对的进程组成，在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）。
• 通常将两个进程之一标识为客户，另一个标识为服务器。
  
  • 在给定的一对进程之间的通信会话场景中，发起通信的进程被标识为客户，在会话开始时等待联系的进程是服务器。

进程与计算机网络之间的接口

• 进程通过套接字（socket）在网络上发送/接收报文
• 套接字类似每个人房间门前的信箱，发送端应用程序将报文放进套接字这一端，在套接字另一端，运输层协议（TCP/UDP）负责使该报文进入接收进程的套接字（将报文放到另一个人房间门前的信箱）。
• 套接字也被称为应用程序和网络之间的应用程序编程接口（API）。
• 程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权，除了：
  
  1. 选择运输层协议（如果可供选择的话）
  2. 也许能设定几个运输层参数，如最大缓存和最大报文段长度
• 

进程寻址

• 一台主机的进程向另一台主机的进程发送分组，接收进程需要一个地址。为了标识该进程，需要定义两种信息：
  
  1. 主机的地址：用IP地址标识；
  2. 定义在目标主机中的接收进程的标识符：用目的地端口号标识。

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

• 根据运输层协议为应用层程序提供的服务，按下列要求进行分类：
  
  • 可靠数据传输：是否容忍数据丢失
  • 吞吐量 ：应用程序是否对吞吐量有特定的要求，若是，则称为带宽敏感的应用，否则称为弹性应用。
  • 定时：对时延的要求
  • 安全性

2.1.4 因特网提供的运输服务

TCP 服务

• TCP 服务模型包括：
  
  • 面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息，即握手阶段。之后，一条全双工的TCP连接就在两个进程的套接字之间建立了。应用程序结束发送报文时，则拆除该连接。
  • 可靠的数据传送服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。
• TCP 协议还具有拥塞控制机制：
  
  • 当发送方和接收方之间的网络出现拥塞时，TCP 的拥塞控制机制会抑制发送进程。
  • TCP 拥塞控制机制也试图限制每个 TCP 连接，使他们达到公平共享网络带宽的目的。
  • 这种服务不一定为通信进程带来直接好处，但是能为因特网带来整体好处。

UDP 服务

• UDP 是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
• UDP 是无连接的，因此在两个进程通信之前无握手。
• UDP 协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进 UDP 套接字时，UDP并不保证该报文到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。
• UDP 没有包括拥塞控制机制，所以 UDP 的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

因特网运输协议所不提供的服务

• TCP 能提供可靠的数据传输服务，也能通过 SSL 来加强以提供安全服务。
• 今天的因特网通常能够为时间敏感应用提供满意的服务，但不能提供任何定时或带宽保证。

TCP/UDP应用

2.1.5 应用层协议

• 应用层协议定义了运行在不同端系统上的进程如何相互传递报文。
  
  • 交换报文的类型，例如请求报文和响应报文。
  • 各种报文类型的语法，如报文中各个字段及这些字段是如何描述的。
  • 字段的语义，即这些字段中包含的信息的含义。
  • 一个进程何时以及如何发送报文，对报文进行响应的规划。

2.2 Web 和 HTTP

2.2.1 HTTP 概况

• Web 的应用层协议是 超文本传输协议（HTTP） ，它是 Web 的核心。
• HTTP 由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话。
• HTTP 使用 TCP 作为它的支撑运输协议。
  客户首先发起一个与服务器的 TCP 连接。一旦该连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。
• HTTP 是一个 无状态协议 。服务器向客户发送被请求的文件，而 不存储 任何该客户的状态信息。
• Web 使用了 客户-服务器 应用程序体系结构。

2.2.2 非持续连接和持续连接

非持续连接

• 应用程序在采用非持续连接的情况下，客户的每个请求都要建立一个单独的 TCP 连接。
• 简单估算一下从客户请求 HTML 文件到客户收到文件为止所花费的时间。
  
  • 下图中，往返时间（RTT）：一个短分组从客户到服务器然后再返回客户所花费的时间。
    
  • 因此，粗略的讲，总的响应时间就是两个 RTT 加上服务器传输 HTML 文件的时间。

持续连接

• 在采用持续连接的情况下，服务器再发送响应后保持该 TCP 连接打开。再相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。
• 一般来说，如果一条连接经过一定的时间间隔（一个可配置的时间间隔）仍未被使用，HTTP 服务器就关闭该连接。
• HTTP 的默认模式是使用带流水线的持续连接。

例子

答案：
获取 IP 地址耗时：RTT1+RTT2+RTT3+……+RTTn
建立 TCP 连接耗RTT0
请求和接受对象耗时RTT0
即三次握手过程要耗时2RTT0
所以总耗时为：RTT1+RTT2+RTT3+……+RTTn+2RTT0
扩展：假定在同一服务器上某 HTML 文件引用了8个非常小的对象。忽略发送时间，在下列情况下需要多长时间：
a、没有并行 TCP 连接的非持续 HTTP
b、配置有5个并行连接的非持续 HTTP
c、持续 HTTP
答案：
a、没有并行 TCP 连接的非持续 HTTP ，每个小对象都要单独建立一个 TCP 连接然后请求和接受对象，即每个小对象额外耗时2RTT0：
RTT1+RTT2+RTT3+……+RTTn+2RTT0+8*2RTT0=
RTT1+RTT2+RTT3+……+RTTn+18RTT0
b、配置有5个并行连接的非持续 HTTP ，并行，所以一次5个，总共只需要建立两次 TCP 连接和请求接受对象：
RTT1+RTT2+RTT3+……+RTTn+2RTT0+2*2RTT0=
RTT1+RTT2+RTT3+……+RTTn+6RTT0
c、持续 HTTP ，由于是持续的，所以 TCP 连接一直打开，不用再建立，只需要额外单独一次请求和接受对象即可：
RTT1+RTT2+RTT3+……+RTTn+2RTT0+RTT0=
RTT1+RTT2+RTT3+……+RTTn+3RTT0

2.2.3 HTTP 报文格式

HTTP 请求报文

GET /boyfriend/memory.html HTTP/1.1
Host: www.xinxin.org
Connection: close
User-agent: Chrome/57.0
Accept-language: ch

• 一个请求报文可以具有更多的行或者至少位一行。
• 第一行叫做 请求行 ，其后继的行叫做 首部行 。
  
  • 请求行有三个字段：
    
    • 方法字段：包括 GET、POST、HEAD、PUT 和 DELETE。绝大部分报文使用 GET 方法。
    • URL 字段
    • HTTP 版本字段
  • 首部行 Host: www.xinxin.org 指明了对象所在的主机。
  • 首部行 Connection: close 要求服务器发送完请求的对象后就关闭该连接。
  • 首部行 User-agent: Chrome/57.0 用来指明用户代理，即向服务器发送请求的浏览器的类型。
  • 首部行 Accept-language: ch 指明了用户想要得到该对象的中文版本。
• 下图是请求报文的通用格式
  
• 首部行后面的 实体主体(Entity body)，在使用 GET 方法时为空，使用 POST 方法时才使用到该实体体。

HTTP 响应报文

对刚才的请求报文的响应报文：

HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ......)

• 响应报文分为三个部分：
• 一个初始 状态行
  
  • 状态行有三个字段：版本协议字段、状态码和相应状态信息。
• 6个首部行

• 实体主体

• 下表包括了一些常用的状态码和相关短语

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

• 下图是响应报文的通用格式
  

2.2.4 用户与服务器的交互：cookie

• HTTP 是无状态的，但是 Web 站点通常希望能够识别用户，为此，HTTP 使用了 cookie ，它允许站点对用户进行跟踪。
• cookie 有 4 个技术组件：
• 在 HTTP 响应报文中的一个 cookie 首部行；
• 在 HTTP 请求报文中的一个 cookie 首部行；
• 在用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理；
• 位于 Web 站点的一个后端数据库。
• cookie 的工作过程如下图
  
• 在web站点后台有数据库。其工作原理是，用户第一次访问某服务器时，其响应报文中包含一个Set-cookie字段，该字段的值往往是服务器设定的唯一标识码，浏览器将该字段和服务器主机名等信息保存在本地，以后用户每次访问时，浏览器都会从cookies中找到该站点的标识码放在请求报文中发送，这样服务器就能通过这个唯一标识辨认这个用户，通过用户在网站上的浏览记录采取行为。

2.2.5 Web 缓存

• Web 缓存器也叫 代理服务器，是能够代表 Web 服务器来满足 HTTP 请求的网络实体。
• Web 服务器有自己的磁盘存储空间，并在存储空间中保存着最近存储过的对象的副本。
• 可以配置用户的浏览器，使得用户所有的 HTTP 请求首先指向 Web 缓存器。
• 客户与 Web 缓存器之间的速度通常比较快，所以可以提高访问的速度，降低时延。
• 客户通过 Web 缓存器请求对象
  
• 当浏览器申请一个文件时，先建立一个到web缓存的TCP连接，如果缓存服务器上有这个文件就返回，否则，他就建立一个到原始服务器的TCP获得该文件并存储，之后将该文件发回客户端。web缓存可以大幅减少对客户端的响应时间，减少机构内部网络和internet之间的链路通信量并节约带宽。这样会带来的新的问题是，web缓存上的文件可能是陈旧的。为此HTTP引入了条件get，即web缓存在保存一个文件时会记录其最后修改时间，客户端每次请求文件时，web缓存会向原始服务器发送一个带有if-modified-since的报文，如果该文件没有改动就直接把缓存中的文件返回给用户，否则重新下载该文件。

2.2.6 条件 GET 方法

• 用来解决 Web 缓存器中的对象拷贝可能是旧的的问题。
• 若同时满足以下两点的则称为 条件 GET 方法：
  
  • 请求报文使用 GET 方法。
  • 请求报文中包含一个 If-Modified-Since: 首部行。
• 
• 

2.3文件传输协议：FTP

用两个并行TCP连接，一个控制连接，一个是数据连接。

2.4 因特网中的电子邮件

• 电子邮件系统有 3 个主要组成部分：
  
  • 用户代理
  • 邮件服务器
  • 简单邮件传输协议（SMTP）
    

2.4.1 SMTP

• SMTP 是因特网中电子邮件中主要的应用层协议。它使用 TCP 可靠数据传输。
• SMTP 限制所有的邮件报文只能采用简单的 7 比特 ASCII 表示。
• 一个简单的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱上。如下图。
  
• 如果 Bob 的邮件服务器没有开机，该报文会保留在 Alice 的邮件服务器上并尝试进行新的尝试。这意味着邮件并不会在中间的某个邮件服务器存留。
• 注意：SMTP 一般不使用中间服务器发送邮件，即使这两个邮件服务器位于地球的两端也一样。
• SMTP 用的是 持续链接：如果发送邮件服务器有几个报文发往同一个接收邮件服务器，它可以通过同一个 TCP 连接发送所有的的报文。

2.4.2 与 HTTP 的对比

• 相同点：
  
  • 都用于从一台主机向另一台主机传送文件。
  • 都使用持续连接。
• 不同点：
  
  • HTTP 是一个 拉协议，TCP 连接是由想要接收文件的机器发起的。SMTP 是一个 推协议，TCP连接是由想要发送文件的机器发起的。
  • SMTP 要求报文必须按照 7 比特 ASCII 码进行编码。HTTP 则没有这种限制。
  • 在处理包含多种不同类型的文档时。HTTP 把每个对象封装到它自己的 HTTP 响应报文中，SMTP 则把所有报文对象放在一个报文中。
  • 因为SMTP要求所有对象用ASCII编码，对于图片、视频或者非ASCII字符，就要使用多用途Internet 邮件扩展（MIME）对其添加支持。需要在报文的首部中添加Content-Type和Content-Transfer-Encoding。
  • SMTP的接收方在受到报文后，会在该报文中添加一个Received行表示接受信息。

2.4.4 邮件访问协议

• 第三版的邮局协议（POP3）
• 因特网邮件访问协议（IMAP）
• 基于 Web 的电子邮件（HTTP）
• 下面考虑邮件如何从接收方的服务器到达接收方主机上的用户代理，也就是邮件访问协议。当用户代理打开一个到邮件服务器的110端口的TCP后，POP3就开始工作了。
  
  • 第一阶段：特许阶段，用户代理以明文发送用户名和密码
  • 第二阶段：事务处理，这个阶段中用户代理将取出服务器上的报文，还可以将一些报文标记为删除。
  • 第三阶段：更新，服务器将删除那些标记了删除的报文。

2.5 DNS：因特网的目录服务

因特网上的主机的标识有2种方式

• 主机名，如www.baidu.com
• IP地址，如xxx.xxx.xxx.xxx

这两种标识其实指代的是同一样东西，就如你父亲叫你全名和叫你儿子是一样的一个道理。那为什么需要2种标识呢？
因为我们人类喜欢主机名这种便于记忆的标识，而对路由器来说，它更喜欢定长的、有层次结构的IP地址。我们在浏览器的地址上输入网址时都是输入其主机号。
所以我们需要一种能进行主机名到IP地址转换的服务，也就是域名系统(Domain Name System，DNS)。

2.5.1 DNS 提供的服务

• 主机可以使用 主机名 和 IP 地址 进行标识。
• DNS 提供从主机名到 IP 地址的目录服务。当主机需要解析一个URL时，发出一个DNS请求，主机上的DNS接收到后发送给DNS服务器，服务器返回解析IP。
• DNS 即 域名系统 是：
  
  • 一个由分层的 DNS 服务器 实现的分布式数据库。
  • 一个使得主机能够查询分布式数据库的应用层协议。
• DNS 协议基于 UDP ，使用 53 端口。
• DNS也是应用层协议，它通常会被其他应用层协议所使用，包括HTTP、SMTP和FTP，将用户的主机名解析为 IP 地址。
• DNS 还提供了一些重要的服务：
  
  • 识别主机别名（用于HTTP、FTP）
  • 识别邮件服务器别名（用于SMTP）
  • 负载分配

2.5.2 DNS 工作机理概述

• DNS服务器采用分布式、层次数据库
  
• 有三种类型的 DNS 服务器：
  
  • 根 DNS 服务器
  • 顶级域（DNS）服务器
  • 权威DNS服务器
• DNS缓存
  
  • 与Web缓存器一样，DNS服务器同样有缓存器。
  • DNS服务器也有分级设定，并通过递归和迭代查询获取IP。当DNS服务器得到一个DNS回答时将在一段时间内保存该解析至缓存，这样可以有效减少递归查询的数量。