应用层协议原理
1、应用程序体系结构application architecture（如何组织端系统应用程序）
客户-服务器 client-server：固定周知IP、数据中心
P2P：流量密集型、自扩展型、高度非集中式
2、进程通信
C/S：C 发起通信、下载；S 等待联系、上载
应用程序接口/套接字（应用层和运输层之间的接口）：可选择、制定一些参数
寻址：IP、端口号 http://www.iana.org
3、运输服务
可靠数据传输：确保数据交付
吞吐量：发送进程向接收进程交付的比特率；以特定速率确保可用的吞吐量
定时：为了有效性而要求数据交付有严格时间限制
安全性：加密、端点鉴别、数据完整性
4、运输层协议
TCP：面向连接；可靠数据传输；拥塞控制
SSL：TCP加强版；加密、端点鉴别、数据完整性
UDP：无连接；不提供不必要服务；任意速率注入数据
运输协议不提供的服务：吞吐量、定时；防火墙阻挡UDP流量、TCP备份
5、应用层协议（公共域RFC文档、专用协议）
报文类型；报文语法；字段语义；响应规则
Web和HTTP（RFC 2616）80端口
Web页面：HTML、JPEG、Java文件；HTTP：超文本传输协议 HyperText Transfer Protocol
Web浏览器（IE、Firefox）、Web服务器（Apache、MIIS）
无状态stateless协议：不保存客户的任何信息
1、持续/非持续连接
HTTP默认持续连接，可配置非持续；浏览器默认打开5～10个并行的TCP连接，并行连接缩短响应时间
持续persistent connection：请求响应对通过相同TCP连接；非持续non-persistent：单独TCP连接
RTT：往返时间Round-Trip Time=传播时延+排队时延+处理时延；一般2*RTT+文件传输时间
HTTP1.1：超时关闭连接；HTTP/2（RFC 7540）：问答机制
2、HTTP报文格式
请求：
代码：
//请求行 GET /somedir/page.html HTTP/1.1 //请求一个对象 //首部行 Host: www.someschool.edu //主机，Web代理高速缓存要求 Connection: close User-agent: Mozilla/5.0 //用户代理，浏览器类型 Accept-language: fr //等等
POST：表单生成的请求报文（GET+扩展URL）
HEAD：不返回请求对象的请求报文
PUT：上传对象
DELETE：删除对象
响应：
代码：
//状态行 HTTP/1.1 200 OK //协议版本，状态码，状态信息 //首部行 Connection: close Date: 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/htm l//对象类型 //实体体 (data data data data ...)//报文
200 OK：请求成功
301 Moved Permanently：对象已永久转移
400 Bad Request：请求不能被服务器理解
404 Not Found：文档不在服务器上
505 HTTP Version Not Supported：HTTP协议版本不支持
利用telnet（RFC 854）程序可以登陆到Web服务器上：
telnet gaia.cs.umass.edu 80 GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu
（终端使用者可以在telnet程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个telnet会话，必须输入用户名和密码来登录服务器。Telnet是常用的远程控制Web服务器的方法。）
3、cookie （RFC 6265）
（HTTP无状态简化了服务器设计，利用cookie可以识别用户。）
cookie技术组件：HTTP响应首部行；HTTP请求首部行；用户端系统cookie文件夹；Web站点数据库
4、Web缓存
（也叫代理服务器。）
定义：能够代表初始Web服务器，满足HTTP请求的网络实体。Web缓存器一般由ISP购买安装。
原因：迅速将对象交付给用户；减少机构接入英特网的通信量；
CDN：内容分发网络
5、条件GET
（高速缓存副本更新问题）
//1.请求报文 GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecuisine.com //响应报文 HTTP/1.1 200 OK Date: Sat, 3 Oct 2015 15:39:29 Server: Apache/1.3.0 (Unix) Last-Modified: Wed, 9 Sep 2015 09:23:24 Content-Type: image/gif (data data data data ...) //2."条件"请求报文 GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecuisine.com If-modefied-since: Wed, 9 Sep 2015 09:23:24 //响应报文 HTTP/1.1 304 Not Modified //没有改进、更新 Date: Sat, 10 Oct 2015 15:39:29 Server: Apache/1.3.0 (Unix) (empty entity body)
Email和SMTP（RFC 5321）25端口
（异步通信媒介）组成部分：用户代理 User Agent；邮件服务器 mail server；SMTP，Simple Mail Transfer Protocol 简单邮件传输协议；
HTTP 主要是拉协议（pull protocol）：用户使用HTTP从服务器拉取信息；HTTP把每个对象封装到它自己的HTTP响应报文中；
SMTP 基本是推协议（push protocol）：文件被推向接收邮件服务器；SMTP把所有报文对象放在一个报文之中；
1、SMTP
限制体部分为7比特ASCII表示，多媒体需编码解码。SMTP 一般不使用中间邮件服务器发送邮件。SMTP是持续连接。
SMTP握手协议：
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MALL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr ... Sender ok C: RCPT TO: <bob@hambuger.edu> S: 250 bob@hambuger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
报文首部行：
From: alice@crepes.fr To: bob@hamburger.edu Subject: Searching for the meaning of life.
Telnet程序：
telnet serverName 25
2、邮件访问协议
邮件访问使用C/S体系结构。
（Alice的用户代理，用SMTP将电子邮件推入她的邮件服务器，她的邮件服务器再用SMTP，将邮件中继到Bob的邮件服务器，Bob通过特殊邮件访问协议，拉取邮件。）
POP3（RFC 1939）110端口，第三版的邮局协议
工作构成：特许（鉴别用户）；事务处理（取回报文，删除标记）；更新（服务器删除被标记的报文）；
特许：
telnet mailServer 110 +OK POP3 server ready user bob +OK pass hungry +OK user successfully logged on //+OK 前面命令正常 //-ERR 前面命令错误
事务处理：
C: list S: 1 498 //存储的报文长度 S: 2 912 S: . C: retr 1 S: (...) S: . C: dele 1 C: retr 2 S: (...) S: . C: dele 2 C: quit S: +OK POP3 server signing off
IMAP（RFC 3501），因特网邮件访问协议
为用户创建远程服务器的层次文件夹。IMAP服务器维护IMAP会话的用户状态信息。允许用户代理只获取报文的某些部分。
HTTP，基于Web的电子邮件
用户和他的远程邮箱通过HTTP通信。
DNS（RFC 1034/1035）53端口
域名系统 Domain Name System。DNS服务器通常是运行BIND软件的UNIX机器。使用UDP协议，C/S模式，端到端运输协议。
主机名 / IP地址：主机的一种标识方法
主机别名：复杂主机名的主机可以拥有多个别名，别名比规范主机名更容易记住
邮件服务器别名：MX记录允许一个公司的邮件服务器和Web服务器使用相同的主机别名
负载分配：IP地址集合与一个规范主机名相联系，冗余DNS服务器循环分配负载
1、DNS工作机理
分布式层次数据库
没有一台DNS服务器拥有英特网上所有主机的映射。
根DNS服务器：根DNS服务器提供TLD服务器的IP地址，400多个根服务器由13个不同组织管理
顶级域TLD DNS服务器：TLD服务器提供权威DNS服务器的IP地址，每个顶级域（com、org、net、edu、gov）和所有国家顶级域（uk、fr、ca、jp）都有TLD服务器
权威DNS服务器：权威DNS服务器收录每个组织机构提供的可访问DNS记录，这些记录将主机名映射为IP地址
本地DNS服务器（LDNS）：每个ISP都有一台本地DNS服务器，主机发出的DNS请求，由本地DNS服务器代理发往DNS服务器层次结构中
递归查询 / 迭代查询：请求从主机到本地DNS服务器是递归的，其余查询是迭代的
注册登记机构
ICANN向各种注册登记机构授权。http://www.internic.net
DNS动态更新（RFC 2136 / 3007）。提供你的基本和辅助权威DNS服务器名字和IP地址，便可以注册域名到DNS系统中。
(networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)
DNS缓存
DNS caching 能将映射缓存在本地存储器中。由于映射不是永久的，DNS服务器在一段时间后（两天），丢弃缓存信息。所以本地DNS可以绕过TLD和根DNS服务器。一定程度上增加了DNS的健壮性。
2、DNS记录和报文
RR，资源记录Resourse Record：（Name，Value，Type，TTL）//TTL是记录生存时间
Name和Value取决于Type：
Type=A：（Name：主机名，Value：IP地址）标准主机名到IP地址的映射 //（relay1.bar.foo.com，145.37.93.126，A）
Type=NS：（Name：域，Value：权威DNS服务器主机名）查询该域中IP地址所在的权威DNS服务器 // （foo.com，dns.foo.com，NS）
Type=CNAME：（Name：规范主机名，Value：别名）查询规范主机名 //（foo.com，relay1.bar.foo.com，CNAME）
Type=MX：（Name：规范主机名，Value：别名）邮件服务器与其他服务器有相同的别名 //（foo.com，mail.bar.foo.com，MX）
DNS查询和回答有着相同的报文：
标识符：匹配请求和回答；标志：（查询，0）（回答，1）（权威的）（希望递归）；
利用nslookup程序，可以直接向某些DNS服务器发送DNS查询报文。
P2P文件分发
成对间歇连接的主机彼此直接通信。
1、扩展性
分发时间：所有N个对等方得到文件副本的时间，D_cs vs D_p2p
D_cs >= max{ NF/us，F/dmin }
服务器：分发最短时间 NF(bit)/us(上载速率)
对等方：获得文件最短时间 F/dmin(最小下载速率)
D_p2p >= max{ F/us，F/dmin，NF/(us+ui) }
服务器：分发最短时间 F(bit)/us(上载速率)
对等方：获得文件最短时间 F/dmin(最小下载速率)
系统整体：最小分发时间 NF/(us+ui)(总上载能力）
2、BitTorrent
洪流：参与一个特定文件分发的所有对等方集合
块：对等方彼此交换的文件（一般256KB），下载同时也上载
追踪器：洪流中的基础设施节点，注册并周期性检查对等方
最稀缺优先：优先请求邻居中副本最少的块
疏通：（对换算法）周期性计算并调整对等方集合，优先提供数据给最高请求速率，其他对等方被阻塞（“一报还一报”）
视频流和内容分发网
DASH，经HTTP的动态适应性流 Dynamic Adaptive Streaming over HTTP：视频被编码为不同的版本，响应客户动态请求的视频段数据块。HTTP服务器里的告示文件为每个版本提供一个URL和比特率，客户通过速度决定算法来选择下次请求的块，DASH允许客户自由地切换不同的质量等级。
CDN，内容分发网 Content Distribution Network：CDN服务器存储副本，并将每个用户定向到最佳的CDN位置。
1、CDN
安置原则：
深入：在接入ISP中部署服务器集群，改善时延和吞吐量，但维护和管理难
邀请做客：少量IXP中建造大集群，低维护和管理开销，稍高时延稍低吞吐量
操作：利用DNS截获和重定向请求。
集群选择策略：略（主要是讲的太乱了。。。）
2、Netflix、YouTube、看看
Netflix：直接告知客户使用一台特殊CDN服务器，使用DASH适应性流。Netflix CDN使用推高速缓存。
YouTube：使用DNS重定向，使用HTTP流，集群选择策略平衡RTT和平均负载。谷歌CDN使用拉高速缓存。
看看：混合CDN-P2P流式系统。客户从CDN获得开头部分，当P2P总流量满足视频播放时，客户仅从对等方获得流。
套接字编程 py
1、UDP
客户：
from socket import * serverName = 'hostname' serverPort = 12000 clientSocket = socket(AF_INET, SOCK_DGRAM) //IPv4, UDP message = raw_input('Input lowercase sentence :') clientSocket.sendto(message.encode(), (serverName,serverPort)) modifiedMessage, serverAddress = clientSocket.recvfrom(2048) print(modifiedMessage.decode()) clientSocket.close()
服务器：
from socket import * serverPort = 12000 serverSocket = socket(AF_INET, SOCK_DGRAM) //IPv4, UDP serverSocket.bind((' ', serverPort)) print("The server is ready to receive ") while True: message, clientAddress = serverSocket.recvfrom(2048) modifiedMessage = message.decode().upper() serverSocket.sendto(modifiedMessage.encode(), clientAddress)
2、TCP
客户：
from socket import * serverName = 'servername' serverPort = 12000 clientSocket = socket(AF_INET, SOCK_STREAM) //TCP clientSocket.connect((serverName, serverPort)) sentence = raw_input('Input lowercase sentence :') clientSocket.send(sentence.encode()) modifiedSentence = clientSocket.recv(1024) print('From Server :', modifiedSentence.decode()) clientSocket.close()
服务器：
from socket import * serverPort = 12000 serverSocket = socket(AF_INET,SOCK_STREAM) serverSocket.bind((' ', serverPort)) serverSocket.listen(1) //请求连接数 print('The server is ready to receive ') while True: connectionSocket, addr = serverSocket.accept() sentence = connectionSocket.recv(1024).decode() capitalizedSentence = sentence.upper() connectionSocket.send(capitalizedSentence.encode()) connectionSocket.close()
参考资料：
《计算机网络——自顶向下方法》James F.Kurose 、Keith W.Ross 著
本文采用CC BY 4.0知识共享许可协议。