《计算机网络自顶向下方法》学习笔记。之前学习过计算机网络微课，已经对计网中的很多概念都有了印象和一定的了解了，这时候再读自顶向下感觉比较轻松了。但是自己还是更喜欢自底向上的方式，因为自顶向下时，尽管只需要知道下层能为上层提供服务，但是对下层的大致了解没有建立，感觉并不够顺畅。这本书没有涉及太多物理层的内容，第一章为概述。从第二章应用层开始，自顶向下讲解计算机网络。以下是阅读笔记。

第二章应用层

本章的内容主要是网络应用的相关原理，网络应用的实例(Web，电子邮件，DNS，视频流)，以及简单的网络应用开发(主要学习套接字接口)。

1.应用层协议原理

1.1 应用程序体系结构

客户服务器体系结构
对等体系结构(P2P)

客户-服务器体系结构中，服务器服务来自许多其他客户主机的请求、客户之间不进行通信。服务器通常有确定的地址(IP地址)，客户通过IP地址向服务器请求服务。为了能够处理请求，通常有配备大量主机的数据中心作为虚拟服务器，而不是单独的服务器主机进行服务。

P2P体系结构下，主机之间相互通信，他们被称为对等方。许多流量密集型应用都是P2P体系结构。P2P体系的特性是其具有自扩展性，每个对等方由于请求产生工作负载，同时也分发文件为系统增加服务能力。P2P体系结构不需要庞大的服务器基础设施和带宽，但由于高度非集中式结构，有安全性、性能、可靠性方面的挑战。

1.2 数据通信

两个不同端系统上的进程，通过报文来通信。网络应用程序由成对的进程组成，他们通过网络相互发送报文。两个进程常被标识为客户与服务器。发起通信的进程被标识为客户，在会话开始时等待联系的进程是服务器。

进程是通过称为套接字的软件接口来发送和接收报文的。套接字是应用程序和网络之间的应用程序编程接口。对于套接字，后续有详细的讨论。

两进程间通信，发送分组的进程需要知道接收分组的进程地址。地址由两部分构成：主机地址；主机中接收进程的标识符。这两部分由IP地址和目的地端口号来标识。

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

运输层为应用层提供服务，应用程序服务的要求有以下四个方面：

可靠数据传输
吞吐量
定时
安全性

1.4 因特网提供的运输服务

TCP服务
- 面向连接
- 可靠数据传输
- 安全性：安全套接字层(SSL)加强了TCP，提供安全服务
UDP服务：仅提供最小服务，无连接，不保证报文到达接收进程。

定时和吞吐量是因特网运输协议不能保证的，但通常因特网是可以为时间敏感应用提供满意的服务的。

2.Web和HTTP

2.1 HTTP概况

Web的应用层协议是超文本传输协议HTTP，客户程序和服务器程序中通过HTTP报文进行会话。

Web页面由对象组成，一个对象是一个文件。
Web浏览器实现了HTTP的客户端，Web服务器是HTTP的服务器端。
HTTP是一个无状态协议：服务器不保存关于客户的任何信息。

2.2 非持续连接和持续连接

每个请求响应对是经一个单独的TCP连接发送，则为非持续连接(HTTP1.0)。
所有的请求及响应经相同的TCP连接发送，则为持续连接(HTTP1.1)。HTTP在默认方式下使用带流水线的持续连接，允许请求连续发出，而不需要等待未决请求的回答。

2.3 HTTP报文格式

HTTP请求报文

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

请求报文的第一行为请求行，包含方法字段，URL字段和HTTP版本字段，后继的行为首部行，包含了主机地址及连接方式等信息。在首部行后还有一个实体体，用于POST方法。共有5种方法：GET,POST,HEAD,PUT,DELETE。其中最常用的是GET方法，包括提交表单时也可以使用GET方法。

HTTP响应报文

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

响应报文包含三个部分：初始状态行，首部行，实体体。其中初始状态行包含了协议版本，状态码和相应状态信息。以下是常见的状态码：

200 OK
301 Moved Permanently
400 Bad Request
404 Not Found
505 HTTP Version Not Supported

HTTP是一个无状态协议，服务器不保存用户的信息。使用cookie可以让服务器标识一个客户，提供服务。cookie有以下4个组件：

响应报文中的一个cookie首部行
请求报文中的一个cookie首部行
用户端系统中保留一个cookie文件，由浏览器管理
位于Web站点的一个数据库，记录用户信息

2.5 Web缓存

Web缓存器也叫代理服务器，能够代表初始Web服务器满足HTTP请求。Web缓存器可以在存储器空间中保留最近请求过的对象的副本。使用Web缓存器可以大大减少对客户请求的响应时间，还能够大大减少一个机构的接入链路到因特网的通信量。Web缓存器通常由ISP购买和安装。

Web缓存器带来的一个问题是存放在缓存器中的副本可能不是最新的，因此需要有方式去证实请求的对象是最新的。解决这个问题的方式是使用条件GET方法，在首部行中添加"If-Modified-Since"，这样只在指定日期后对象被修改过，才发送该对象。

3.因特网中的电子邮件

因特网邮件系统有三个主要组成部分：用户代理，邮件服务器，简单邮件传输协议(SMTP)。

发送邮件的过程如下：用户代理------>邮件服务器-----SMTP----->邮件服务器----->用户代理

用户代理允许用户阅读、回复、转发、保存和撰写报文。
邮件服务器负责发送和接收邮件，服务器上有一个邮箱，管理和维护着接收到的报文。
SMTP是电子邮件使用的应用层协议，使用该协议从发送方的邮件服务器向接收方的邮件服务器发送邮件。
- SMTP一般不使用中间邮件服务器发送邮件，而是两个服务器之间发送。
- SMTP限制报文体只能采用简单的7bitASCII表示。
- SMTP使用持续的TCP连接发送报文。

SMTP与HTTP的对比
- HTTP是一个拉协议，SMTP是一个推协议。
- SMTP要求每个报文采用7bitASCII码格式
- HTTP将每个对象封装到自己的HTTP响应报文中，而SMTP把所有报文对象放在一个报文之中。

SMTP是一个推协议，由发送邮件的服务器将文件发给接收邮件的服务器，接收邮件的用户是不能使用该协议获取接收到的邮件的。获取接收到的邮件使用的是邮件访问协议。流行的邮件访问协议有：第三版的邮局协议POP3；因特网邮件访问协议IMAP。

POP3

POP3协议简单，但功能有限。用户代理打开与邮件服务器的TCP连接后，POP3开始工作。POP3工作有三个阶段：

特许：用户代理发送用户名和口令以鉴别用户。
事务处理：用户代理取回报文，对报文进行删除标记，取消删除标记，获取邮件的统计信息。获取报文有以下两种方式：
- 下载并保留
- 下载并删除
更新：结束POP3会话，删除被标记为删除的报文。

IMAP

使用POP3协议只能获取报文，不能在服务器上创建文件夹对报文进行管理。为了解决这个或一些其他问题，产生了IMAP协议。IMAP服务器把每个报文与一个文件夹联系起来，报文到达时与INBOX文件夹相关联，而收件人能够把邮件移到一个新的文件夹中，阅读，删除或是移动到别的文件夹。IMAP还提供了查询邮件的命令，且IMAP维护了IMAP会话的用户状态信息(文件夹的名字等)。另外，IMAP还允许用户代理获取报文某些部分的命令。这样当用户处于低带宽连接时，可以选择性的只取回(MIME)报文的一部分。

基于Web的电子邮件

今天，基于Web的邮件已经非常常见了。这种电子邮件，用户代理就是浏览器，用户和远程邮箱之间的通信通过HTTP进行。用户发送和获取电子邮件时，都通过HTTP协议在浏览器和邮件服务器之间进行报文传输，但是邮件服务器之间发送和接收报文仍然使用SMTP。

4.DNS：因特网的目录服务

4.1 DNS概述与DNS服务

因特网上的主机可以使用多种方式标识。一种易于记忆的方式是主机名，而路由器所需要的标识则是更为具体的IP地址。将主机名转换到IP地址，就是域名系统DNS的任务。

DNS是由分层的DNS服务器实现的分布式数据库。
DNS是使主机能够查询分布式数据库的应用层协议。
DNS协议运行在UDP上，使用53端口。

除了进行主机名到IP地址的转换，DNS还提供了以下服务：

主机别名：一个主机除了规范主机名外，还可以有其他别名。通过DNS可以获取别名对应的规范主机名和IP地址。
邮件服务器别名：和主机别名相同，邮件服务器也可以使用别名，通过DNS获取规范主机名和IP地址。
负载分配：一个站点可能会被冗余分布在多台服务器上，有不同的IP地址。这些IP地址构成了一个IP地址集，DNS服务器可以在返回这些IP地址时循环改变次序，客户通常选择先返回的IP地址请求服务，这样通过更改返回IP地址的顺序，就能起到负载分配的作用。

4.2 DNS工作原理

使用单个DNS服务器有单点故障、通信容量，远距离集中(高时延)，维护等问题，因此DNS采用了分布式的设计方案。按照层次，DNS服务器分为三种：根DNS服务器；顶级域服务器；权威DNS服务器。除了以上三个层次外，还有一类重要的DNS服务器是本地DNS服务器。本地DNS服务器一般离主机很近，起到代理的作用。在进行DNS查询时，有两种查询方式：递归查询和迭代查询。通常，请求主机到本地DNS服务器的查询是递归的，其余的查询是迭代的。

为了改善时延性能和减少报文传输，DNS还广泛使用了缓存技术。DNS服务器会缓存主机名/IP地址对，一段时间后才丢弃缓存信息。

5.P2P文件分发

使用P2P体系结构的网络应用对总是打开的基础设施服务器有最小的依赖。P2P体系结构具有内在自扩展性，无论有多少对等方，P2P体系结构的应用的文件分发时间都小于客户-服务器体系结构的应用。BitToreent是一种用于文件分发的流行P2P协议，以下是BitTorrent的部分功能原理。

在BitTorrent协议中，参与一个文件分发的所有对等方的集合称为一个洪流。洪流中的对等方互相下载等长度的文件块(典型长度256KB)。对等方刚进入洪流时没有块，一段时间后就持有了块，并可为其他对等方上载块。每个洪流有一个追踪器，当对等方加入洪流时，将向追踪器注册自己，并周期性通知追踪器自己仍在洪流中。

当一个对等方A加入洪流后，追踪器会给出一个对等方子集及这些对等方的IP地址，A可以从中选择临近的对等方建立TCP连接，交换块列表。选择向邻居请求哪些块使用的策略是最稀缺优先，首先请求邻居中副本最少的块，从而加快这些块的分发。而响应邻居的哪些请求则使用的是一种对换算法，优先响应前四个给A提供数据最高速率的邻居(他们被称为疏通)，并且还会每30s随机选择一个对等方B，如果B的速率够高，就把B换进前四位列表。这样对等方能够趋向于找到彼此的协调的速率上载。除了这五个对等方外，其他相邻的对等方不会收到A的块。这种激励机制被称为“一报还一报”。

6.视频流和内容分发网

6.1 视频流

视频是一系列的图像，可以被压缩，通常用比特率来衡量质量。视频可以被压缩到不同的比特率，让用户根据网络带宽来选择观看的版本。对流式视频最重要的性能度量是平均端到端吞吐量，流式视频应用得到的平均吞吐量至少与压缩视频的比特率一样大。

在HTTP流中，视频只是一个普通的文件。用户请求视频文件，将收到的字节进行缓存，一旦超过了预先设定的门限就开始播放，将字节处理成帧，并将这些帧解压缩展现在视频上。视频编码为不同比特率的版本经HTTP传输，被称为经HTTP的动态适应流(DASH)。使用DASH后，视频有不同版本存放在服务器中，服务器会有一个告示文件，提供每个版本的URL和比特率信息。客户可以根据可用带宽指定URL和一个字节范围，对视频数据块请求。

6.2 内容分发网

因特网视频公式每天都需要向百万计的用户发送数据，如果在数据中心存储所有视频，会产生很大的问题。主要有三个问题：1.如果用户离数据中心太远，很可能产生停滞时延。2.流行的视频可能经相同链路发送多次，浪费带宽。3.单个数据中心出现单点故障，就不能分发视频流了。为了解决分发视频数据的问题，，几乎所有的视频流公司都使用内容分发网CDN。CDN管理分布在多个位置的服务器，将用户请求定位到能提供最好服务的CDN位置。CDN包括专用CDN(内容提供商自己的)和第三方CDN(代表多个内容提供商分发内容)。

CDN通常集群部署。每个集群只保留一些视频，当用户请求视频时，如果集群中没有该视频，再从其他集群或中心仓库拉取视频到集群，并在本地存储一个副本。CDN的部署通常采用两种原则：

深入：在全球接入ISP中部署服务器集群，靠近端用户。
邀请做客：在少量关键的位置建造大集群，邀请ISP做客。

使用CDN，用户的请求需要被重定向到CDN服务器，这通常是由DNS进行截获和重定向的。DNS检测到URL中有video以及内容提供商的名字，就返回一个CDN域的主机名，用户将再次发送请求到这个CDN域的DNS系统，并得到CDN节点的IP地址。CDN的集群选择策略是CDN部署的核心，一种简单的策略是指派用户到地理上最为临近的集群，也有周期性实时测量集群和用户到集群时延和丢包性能来选择集群的策略。

7.套接字编程

网络应用程序有两类，一种使用协议标准(如RFC)定义的操作实现的，另一种是使用专用的应用层协议。如果是开发专用的网络应用程序，应该避免使用熟知端口号。另外一个实现网络应用程序的问题是，该选择TCP还是UDP。这两种协议有各自的特点。以下是分别使用UDP和TCP实现的简单客户-服务器程序(Python实现)。

7.1 UDP套接字编程

# Client
from socket import *

def main():
    serverName = '127.0.0.1'										#本机IP
    serverPort = 12000												#端口
    clientSocket = socket(AF_INET, SOCK_DGRAM)						#IPV4,UDP
    message = input("Input lowercase sentence:")
    clientSocket.sendto(message.encode(), (serverName,serverPort))
    modifiedMessage,serverAddress = clientSocket.recvfrom(2048)
    print(modifiedMessage.decode())
    clientSocket.close()
    return

if __name__ == "__main__":
    main()
    
# Server
from socket import *

def main():
    serverPort = 12000
    serverSocket = socket(AF_INET,SOCK_DGRAM)
    serverSocket.bind(('',serverPort))
    message,clientAddress = serverSocket.recvfrom(2048)
    modifiedMessage = message.decode().upper()
    serverSocket.sendto(modifiedMessage.encode(),clientAddress)

if __name__ == '__main__':
    main()

7.2 TCP套接字编程

# Client
from socket import *

def main():
    serverName = '127.0.0.1'	
    serverPort = 12000
    clientSocket = socket(AF_INET,SOCK_STREAM)						#IPv4,TCP
    clientSocket.connect((serverName,serverPort))					#建立连接
    sentence = input("Input lowercase sentence:")
    clientSocket.send(sentence.encode())							#已建立连接，不需要地址了
    modifiedSentence = clientSocket.recv(2048)
    print("From Server:",modifiedSentence.decode())
    clientSocket.close()

if __name__ == '__main__':
    main()
# Server
from socket import *

def main():
    serverPort = 12000
    serverSocket = socket(AF_INET,SOCK_STREAM)
    serverSocket.bind(('',serverPort))
    serverSocket.listen(1)											#欢迎套接字，等待建立连接
    print("The server is ready to receive")
    while(1):
        connectionSocket,addr = serverSocket.accept()				#客户专用套接字
        sentence = connectionSocket.recv(2048).decode()
        modifiedSentence = sentence.upper()
        connectionSocket.send(modifiedSentence.encode())
        connectionSocket.close()

if __name__ == "__main__":
    main()