计算机网络-第二章-应用层

第2章应用层

原理
实例
编程三个部分

创建一个新的网络应用

编程
- 在不同的端系统上运行
- 通过网络基础设施提供的服务，应用进程彼此通信
- 如Web:Web 服务器软件与浏览器软件通信
网络核心中没有应用层软件
- 网络核心没有应用层功能
- 网络应用只在端系统上存在，快速网络应用开发和部署

因为应用部署的简便以及网络核心部署的快速，网络得以发展地很快

2.1 应用层协议原理

2.1.1 网络应用体系结构

(1) 客户-服务器(C/S)

服务器:

一直运行
固定的IP地址和周知的端口号（约定)
扩展性:服务器场数据中心进行扩展（扩展性差）

客户端:

主动与服务器通信
与互联网有间歇性的连接)
可能是动态IP地址
不直接与其它客户端通信

缺点：

可拓展性差
达到一定能限（阈值），性能暴跌（理想情况下，希望性能随着用户数量增多线性下降，但实际上会断崖式下降）
可靠性差（服务器宕机就完蛋了）

(2) 对等体(P2P)

(几乎）没有一直运行的服务器
任意端系统之间可以进行通信
每一个节点既是客户端又是服务器
- 自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求
  
  （因此随着用户规模的增长，性能不一定是下降，而是维持在一定的程度）
  
  （因此迅雷类似的服务可以很容易的将用户扩大到很多）
参与的主机间歇性连接且可以改变地址
例子:Gnutella，迅雷

缺点：难以管理

(3) C/S和P2P混合

例如Napster

文件搜索：集中
- 主机在中心服务器上注册其资源
- 主机向中心服务器查询资源位置
文件传输：P2P
- 任意Peer节点之间

注册和目录的查询是集中式的，文件的传输是P2P

即时通信

在线检测：集中
- 当用户上线时，向中心服务器注册其IP地址
- 用户与中心服务器联系，以找到其在线好友的位置
两个用户之间聊天：P2P
微信和QQ可以这么认为，但实际上更加复杂

(4) 分布式架构

这里没有细讲，在分布式系统课程中有讲

2.1.2 进程通信及问题

(1) 基本概念

进程:在主机上运行的应用程序

在同一个主机内，使用进程间通信机制通信（操作系统定义，不需要网络)
不同主机，通过交换报文(Message）来通信
- 使用OS提供的通信服务
- 按照应用协议交换报文
- 借助传输层提供的服务
客户端进程：发起通信的进程
服务器进程：等待连接的进程

注意：P2P架构的应用也有客户端进程和服务器进程之分

主动发起请求的是客户端进程，被动接收请求的是服务器进程

(2) 相关问题

分布式进程通信需要解决的问题（应用进程如何使用传输层提供的服务交换报文）

问题1：进程标示和寻址问题 (对于进程谁发/谁收，对等层实体之间) （就是如何标识自己，标识要求是唯一的，而且有寻址功能）
问题2：传输层-应用层提供服务是如何 (上下层间)
- 位置：层间界面的SAP （TCP/IP ：socket）
- 形式：应用程序接口API （TCP/IP ：socket API）
问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（本层间）
- 定义应用层协议：报文格式，解释，时序等
- 编制程序，使用OS提供的API ，调用网络基础设施提供通信服务传报文，实现应用时序等；

总的来说，就是

进程的标识和寻址
应用层如何使用传输层的服务
应用层定义协议

下面着重讲解如何这些问题

(3.1) 进程编址(标识)

进程为了接收报文，必须有一个标识即: SAP(发送也需要标示)
- 主机:唯一的32位IP地址，仅仅有IP地址不能够唯一标示一个进程;
  
  在一台端系统上有很多应用进程在运行
- 所采用的传输层协议:TCP or UDP
- 端口号(Port Numbers) 用来区分不同的应用进程
一些知名端口号的例子:
- HTTP: TCP(Web应用) 80 Mail: TCP 25 ftp: TCP 2
一个进程:主机IP + TCP/UDP + 端口号
本质上，一对主机进程之间的通信由2个端节点（EndPoint）构成

(3.2) 应用层向传输层提供的数据

① 提供的数据

传输层提供的服务-需要穿过层间的信息

层间接口必须要携带的信息

发什么，谁发的，发给谁

也就是发送端应用进程的标识 + 接收端应用进程的标识 + 数据

要传输的报文(对于本层来说:SDU) (SDU——未经本层封装的) （发的什么）
谁传的:对方的应用进程的标示:IP+TCP(UDP)端口（谁发的）
传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号（发给谁）

传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段(UDP数据报)的封装

源端口号，目标端口号，数据等
将IP地址往下交IP实体，用于封装IP数据报:源IP,目标IP

如果Socket API（原语）每次传输报文（穿过层间），都携带如此多的信息，太繁琐易错，不便于管理

用个代号标示通信的双方或者单方: socket

就像OS打开文件返回的句柄一样对句柄的操作，就是对文件的操作

总之发送端应用进程的标识 + 接收端应用进程的标识 + 数据每次都发太麻烦了，所以建立socket连接之后就不用再传了

② socket

a. TCP socket

理解

TCP服务，两个进程之间的通信需要之前要建立连接（两个进程通信会持续一段时间，通信关系稳定）
可以用一个整数表示两个应用实体之间的通信关系，本地标示
穿过层间接口的信息量最小
TCP socket: 源IP,源端口，目标IP，目标IP,目标

socket也就是本地管理的本地的ip+端口地址，对方的ip+端口地址

仅仅是在传输数据的时候不需要发这些信息了，只需要发数据即可

socket就是管理这些，并没有建立什么复杂的内容，比如内存之类的，这些都是底层做的

socket仅仅是保存这些信息，传输是由传输层负责的

在TCP，也就是面向连接的传输中，socket是一个本地标识

TCP socket 是一个整数（类似文件描述符）代表一个四元组（我的IP和端口号对方的IP和端口号）

便于管理

使得穿过层间的信息量最小

是应用层和传输层的一个约定本地会话的标识

说明

对于使用面向连接服务(TCP）的应用而言，套接字是4元组的一个具有本地意义的标识

socket逻辑上表示一个4元组: (源IP，源port，目标IP，目标port)；
从物理上看，TCP socket就是一个整数
唯一的指定了一个会话（2个进程之间的会话关系)
应用使用这个标示，与远程的应用进程通信
不必在每一个报文的发送都要指定这4元组
就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名
优点：简单，便于管理

例子：

可以看到，中间同样一个端口，使用不同的socket，与不同的应用连接

b. UDP socket

UDP服务，两个进程之间的通信需要之前无需建立连接
- 每个报文都是独立传输的
- 前后报文可能给不同的分布式进程
因此，只能用一个整数表示本应用实体的标示（并不代表一个会话关系，因为它是无连接的）

因为这个报文可能传给另外一个分布式进程·1
穿过层间接口的信息大小最小
UDP socket:本IP,本端口
- 但是传输报文时:必须要提供对方IP，port
- 接收报文时:传输层需要上传对方的IP，port

对于使用无连接服务(UDP）的应用而言，套接字是2元组的一个具有本地意义的标识

UDP的socket表示一个2元组: IP，port(源端指定)
UDP套接字指定了应用所在的一个端节点(endpoint)
在发送数据报时，采用创建好的本地套接字(标示ID），就不必在发送每个报文中指明自己所采用的ip和port
但是在发送报文时，必须要指定对方的ip和udp port(另外一个段节点)

使用UDP的时候，应用层要向数据层传递数据本身 + 对方ip + 对方的端口

总结 + 比较

套接字（Socket）

进程向套接字发送报文或从套接字接收报文
套接字<->门户
- 发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
- 接收进程从另外一端的门户收到报文（依赖于传输层设施)

套接字在物理上就是一个整数
逻辑上表示：
1. TCP socket：指定了一个会话，表示一个四元组(源IP，源port，目标IP，目标port)
2. UDP socket：指定了一个应用所在的一个端节点，表示一个二元组(源IP，源port)
优点：
1. 便于管理
2. 使得穿过层间的信息量最小

到此为止，传输层如何应用socket进行传输这是传输层要做的事情

(3.3) 定义应用层协议

定义应用层协议：报文格式，解释，时序等
编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

应用层协议说明

定义了：运行在不同端系统上的应用进程如何相互交换报文

交换的报文类型：请求和应答报文
各种报文类型的语法：报文中的客个字段及其描述
字段的语义：即字段取值的含义进程何时、如何发送报文及对报文进行响应的规则

应用协议仅仅是应用的一个组成部分

应用还包含了其他的内容，比如界面，IO，业务逻辑等与网络交互无关的部分

实体：是指与网络交互有关的部分，但是其他就不叫实体了

实体是实现网络协议的软件模块和硬件模块

Web应用:
- HTTP协议
- web客户端
- web服务器
- HTML(超文本标记语言，HTML不属于http的部分，所以上传下载文件都不需要html，HTML仅仅是如何解析html文件)
公开协议：
- 由RFC文档定义
- 允许互操作
- 如HTTP, SMTP
专用（私有）协议：
- 协议不公开
- 如：Skype（通过网络打电话）

2.1.3 传输层服务要求

(1) 传输层服务指标

① 指标

数据丢失率
- 有些应用则要求100%的可靠数据传输（如文件)
- 有些应用(如音频)能容忍一定比例以下的数据丢失
延迟
- 一些应用出于有效性考虑，对数据传输有严格的时间限制
- Internet电话、交互式游戏等
吞吐
- 一些应用(如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
- 一些应用能充分利用可供使用的吞吐(弹性应用)

也就是有的应用对吞吐量要求不高，如果吞吐量高，那么就能充分应用，吞吐量低也能运行，只不过速率比较慢而已

吞吐量：在源端和目标端之间传输的速率（数据量/单位时间），可以理解为带宽

安全性
- 机密性
- 完整性
- 可认证性（鉴别)

第八章会讲网络的带宽

② 举例

应用	数据丢失率	吞吐	时间敏感性
文件传输	不能丢失	弹性	不
e-mail	不能丢失	弹性	不
Web文档	不能丢失	弹性	不
实时音视频	容忍丢失(丢失了一块不影响整体的信息)	音频: 5kbps-1Mbps 视频: 100kbps-5Mbps	是，100ms
存储音视频(点播)	容忍丢失	同上	是，几秒
交互式游戏	容忍丢失	几kbps-10kpbs	是，100ms
即使讯息	不能丢失	弹性	是或不是

(2) 传输层提供的服务

实体：实行网络协议的软件模块或硬件模块（运行中的）

① TCP服务

可靠的传输服务
流量控制:发送方不会淹没接受方(接收方出了问题)
拥塞控制:当网络出现拥塞时，能抑制发送方(这里是接收方没问题，但是网络出了问题了)
不能提供的服务:时间保证、最小吞吐保证和安全
面向连接:要求在客户端进程和服务器进程之间建立连接

② UDP服务

不可靠数据传输
不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立连接

UDP必要性

能够区分不同的进程，而IP服务不能
- 在IP提供的主机到主机端到端功能的基础上，区分了主机的
  应用进程
无需建立连接，省去了建立连接时间，适合事务性的应用
不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用
- 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发〉
没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
- 而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

(3) 应用举例

Internet应用及其应用层协议和传输协议

应用	应用层协议	下层的传输协议
e-mail	SMTP(RFC 2821)	TCP
远程终端访问	Telnet(RFC 854)	TCP
Web	HTTP(RFC 2616)	TCP
文件传输	FTP(RFC 959)	TCP
流媒体	专用协议(如RealNetworks)	TCP或UDP(大多UDP，但是有些大厂设计防火墙等问题，必须使用TCP，尽管效率低)
Internet电话	专用协议(如Net2Phone)	TCP或UDP(大多UDP)

(4) 安全TCP(SSL)

TCP & UDP 共有的性质

都没有加密
明文通过互联网传输，甚至密码

SSL 提供安全性

在TCP上面实现，提供加密的TCP连接
私密性
数据完整性
端到端的鉴别

SSL在应用层

应用采用SSL（SSL采用库的形式与应用程序一起运行，所以说在应用层上）
SSL 库使用TCP通信

SSL socket API

应用通过API将明文交给socket，SSL将其加密在互联网上传输
详见第8章

https就跑在ssl之上

应用层应用及协议举例

下面介绍应用层的一些应用和支持应用的协议，当然，应用层的协议是所有协议栈中最多的，这里只举几个典型的、基础的例子

2.2 Web应用 & HTTP协议

本章内容仅仅是基础的内容，实际上Web和HTTP还有很多扩展的知识

2.2.1 Web应用

(1) Web页面组成

就是平常使用的浏览器发出请求，返回页面的服务就是Web服务

① 组成结构

Web页:由一些对象组成

（Web页本身就是一个对象，不过内部嵌入了一些对象，不是嵌入的对象本身，而是对象的链接）

（Web页面有一个最基础的 base html，然后html通过链接其他的对象构成了一个网状结构）
对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接)
通过URL对每个对象进行引用，包括访问协议用户名，口令字，端口等；

（任何对象都可以采用URL来访问，任何对象也可以采用URL来唯一标识）

Web应用的代理软件：浏览器

② URL格式

URL格式:

Port://user:psw@www.someSchool.edu/someDept/pic.gif:port

路径元素	含义
Port	协议名
user	用户
psw	口令
www.someSchool.edu	主机名
someDept/pic.gif	路径名
port	端口

用户口令可以不提供，即匿名访问

端口不填可以是默认的：http-80，ftp-21

③ Web页面解析流程

对于一个网页

首先拿到网页的base html
浏览器根据HTML协议解析html文件，画出页面结构
拿出网页中的链接，访问该链接，将响应的文件嵌入到页面中

2.2.2 HTTP协议

HTTP协议是支持web应用的协议

(1) 基本概念

① HTTP概念

HTTP: 超文本传输协议
网络架构：客户/服务器模式(C/S)
- 客户: 请求、接收和显示 Web对象的浏览器
- 服务器: 对请求进行响应，发送对象的Web服务器

版本：
- HTTP 1.0: RFC 1945
- HTTP 1.1: RFC 206

② 连接方式:TCP

HTTP协议使用的都是TCP连接方式

客户发起一个与服务器的TCP连接(建立套接字)，端口号为80（默认是80）
服务器接受客户的TCP连接
在浏览器(HTTP客户端)与Web服务器(HTTP服务器server)交换HTTP报文(应用层协议报文)
TCP连接关闭

连接流程

在服务器开启一个守护端口(TCP socket)：默认是80用来监听来自客户端的请求
接受到请求之后创建新的socket与该请求建立连接，之后与该请求通信的是这个socket
原守护端口依旧用来监听请求

③ 往返时间RRT和响应时间

往返时间RTT（round-trip time）：一个小的分组从客户端到服务器，再回到客户端的时间（传输时间忽略）
响应时间：
- 一个RTT用来发起TCP连接
- 一个RTT用来HTTP请求并等待HTTP响应
- 文件传输时间
共：2RTT+传输时间

如下所示

RTT不包含传输时间，响应时间包含，响应时间 = 2RTT+传输时间

(2) HTTP连接

HTTP 1.0和HTTP1.1的区别

① 非持久HTTP

a. 介绍

非持久HTTP

最多只有一个对象在 TCP连接上发送
下载多个对象需要多个TCP连接
HTTP/1.0使用非持久连接

对象指的是请求或响应的文件内容，比如请求一个视频，服务器响应回来的视频就是对象

HTTP1.0 连接是无状态的

服务器并不维护关于客户的任何信息

也就是服务器相应了之后就关闭了TCP连接，这种服务器叫做无状态服务器

b. 流程举例

当服务端响应了文件之后，HTTP就关闭了TCP连接
也就是每次发出请求都需要先建立TCP连接，响应之后直接关闭连接

c. 维护状态的困难

维护状态的协议很复杂！

必须维护历史信息(状态)
如果服务器/客户端死机，它们的状态信息可能不一致，二者的信息必须是一致
无状态的服务器能够支持更多的客户端

d. 优缺点

优点：简单

缺点

每个对象要2个 RTT
操作系统必须为每个TCP连接分配资源
但浏览器通常打开并行TCP连接，以获取引用对象

② 持久HTTP

a. 介绍

持久HTTP

多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
HTTP/1.1 默认使用持久连接

流程如下：

服务器在发送响应后，仍保持TCP连接
在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求

b. 流水/非流水的持久HTTP

非流水方式的持久HTTP：

客户端只能在收到前一个响应后才能发出新的请求
每个引用对象花费一个RTT

流水方式的持久HTTP：

HTTP/1.1的默认模式
客户端遇到一个引用对象就立即产生一个请求
所有引用（小）对象只花费一个RTT是可能的

(3) HTTP报文

两种类型的HTTP报文：请求、响应
报文都是ASCII可读的，即打印出来是可以直接读的，早期的协议都是这样的

① HTTP请求报文

a. 请求报文格式

HTTP请求报文:

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

下面来解析这个报文

部分	举例	说明
请求行	GET /somedir/page.html HTTP/1.1	命令： GET：获取数据；POST：上载数据；HEAD：仅仅获取相应头部，搜索引擎使用改命令得到头部之后建立索引资源路径：`/somedir/page.html` 协议/协议版本：`HTTP/1.1`
首部行	Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr
实体

HTTP请求报文：通用格式

sp是space空格

cr是回车

if是有可能有，有可能没有

b. 提交表单输入

就是用于添加请求时向服务器提交信息，服务端可以根据信息选择性响应信息

Post方式：

网页通常包括表单输入
包含在实体主体 (entity body )中的输入被提交到服务器

URL方式：

方法：GET
输入通过请求行的 URL字段上载

例子

www.somesite.com/animalsearch?monkeys&banana

http://www.baidu.com/s?wd=xx+yy+zzz&cl=3
参数：wd=xx+yy+zzz  cl=3

c. 请求方法类型

协议版本	请求方式	说明
HTTP/1.0	GET
	POST
	HEAD	要求服务器在响应报文中不包含请求对象 -> 故障跟踪
HTTP/1.1	GET
	POST
	HEAD
	PUT	将实体主体中的文件上载到URL字段规定的路径
	DELETE	删除URL字段规定的文件

② HTTP响应报文

a. 响应报文格式

HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …... 
Content-Length: 6821
Content-Type: text/html


data data data data data ...

下面来逐一解析

部分	举例	说明
状态行	HTTP/1.1 200 OK	HTTP/1.1是协议及版本 200是状态码 OK是状态码相应状态信息
首部行	Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html
数据	data data data data data ...

b. 部分首部行信息

Last-Modified：表示文件上一次修改的时间，可以做版本号，包括后面的缓存一致性检验

Content-Length：6921内容长度，表示在首部部之后读6821个单位的内容

TCP向应用层传播的仅仅是字节流的服务，并不维护报文的边界，需要应用层自己维护区分

HTTP协议通过Content-Length区分

c. 部分状态码

HTTP响应状态码

位于服务器→客户端的响应报文中的首行一些状态码的例子:

状态码	状态信息	说明
200	OK	请求成功，请求对象包含在响应报文的后续部分
301	Moved Permanently	请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定；客户端软件自动用新的URL去获取对象
400	Bad Request	一个通用的差错代码，表示该请求不能被服务器解读
404	Not Found	请求的文档在该服务上没有找到
505	HTTP version Not supported	版本不支持

(4) 命令行发送http请求

使用linux来发送http请求

telnet cis.poly.edu 80

opens TCP connection to port 80 (default HTTP server port) at cis.poly.edu. anything typed in sent to port 80 at cis.poly.edu

就是建立了TCP连接

GET /~ross/ HTTP/1.1 Host: cis.poly.edu

by typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server

(5) 用户-服务器状态：cookies

对应上文的持久HTTP，cookies就是服务器记录客户端请求的方式

① cookie的组成成分

大多数主要的门户网站使用 cookies 4个组成部分：

在HTTP响应报文中有一个cookie的首部行
在HTTP请求报文含有一个cookie的首部行
在用户端系统中保留有一个cookie文件，由用户的浏览器管理
在Web站点有一个后端数据库

② cookie流程

客户端第一次发送请求的时候没有cookie
服务器第一次响应的时候为客户端生成cookie，并返回cookie号
客户端收到相应之后将cookie保存到本地，由浏览器管理
之后的每次请求都会发送这个cookie

例子：

Susan总是用同一个PC使用Internet Explore上网
她第一次访问了一个使用了Cookie的电子商务网站
当最初的HTTP请求到达服务器时，该Web站点产生一个唯一的ID，并以此作为索引在它的后端数据库中产生一个项

Cookies: 维护状态

③ cookie的应用和原理

Cookies能带来什么：

用户验证
购物车
推荐
用户状态 (Web e-mail)

如何维持状态：

协议端节点：在多个事务上，发送端和接收端维持状态
cookies: http报文携带状态信息

④ Cookies与隐私

Cookies允许站点知道许多关于用户的信息
可能将它知道的东西卖给第三方
使用重定向和cookie的搜索引擎还能知道用户更多的信息
如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式
广告公司从站点获得信息

有些网站就要求发送cookie，从而收集到用户的信息进行推荐等用处

2.2.3 Web缓存 (代理服务器)

目标：不访问原始服务器，就满足客户的请求

(1) 流程

用户设置浏览器：通过缓存访问Web （这是需要设置的）
浏览器将所有的HTTP 请求发给缓存
- 在缓存中的对象：缓存直接返回对象
- 如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端

缓存既是客户端又是服务器
通常缓存是由ISP安装 (大学、公司、居民区ISP)

(2) 优点

为什么要使用Web缓存？

降低客户端的请求响应时间
可以大大减少一个机构内部网络与Internent接入链路上的流量
互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容

28定律：80%的人访问20%的内容

(3) 缓存示例

假设

条件

平均对象大小 = 100kb（也就是请求的文件的平均大小是100kb）
机构内浏览器对原始服务器的平均请求率为 = 15请求/s
平均到浏览器的速率：1.5Mbps（100kb * 15请求/s）
接入链路带宽：1.54Mbps 结果

① 相关数据计算

a. 各种延时计算(Internet延时、接入延时、LAN延时)

延时如下：
- Internet延时：公共网(public Internet)路由器到原始服务器再返回到路由器的的延时（ Internet 延时）= 2s；这个也是网络核心的延时吧
- 接入延时：不确定，不过有公式：接入延时（主要还是排队延时）d_queue = I(1-I) * L / R = 2min
- LAN延时：客户端到LAN路由器再返回客户端的时间，为10ms

b. 流量强度和排队延时计算

流量强度 I = 平均到达浏览器的速率 / 接入链路宽带
排队延时 = t_queue = I(1-I) * L / R
L/R：一个分组的传输时间

结果

LAN的流量强度 = 15%
接入链路上的流量强度 = 99% （排队延迟会非常大，排队延迟会随着分组的流量强度越接近于1趋近于无穷，此时排队延迟会非常大）
总延时= LAN延时+ 接入延时+ Internet 延时 = ms + 分+ 2s

流量强度 = 平均到达浏览器的速率 / 接入链路宽带 = 1.5 / 1.54 = 0.99

② 优化方式

a. 提高接入链路带宽

假设：

平均对象大小 = 100kb
机构内浏览器对原始服务器的平均请求率为 = 15请求/s
平均到浏览器的速率：1.5Mbps
接入链路带宽：1.54Mbps——> 154Mbps（带宽提升）
延时：
- Internet延时机构内部路由器到原始服务器再返回到路由器的的延时 = 2s
- LAN延时：客户端到LAN路由器再返回客户端的时间，为10ms

结果

LAN的流量强度 = 15%
接入链路上的流量强度 = 9.9%（可以看到强度降低了很多，排队延时也会下降）
总延时 = LAN延时 + 接入延时 + Internet 延时 = ms + 分 + 2s

代价: 增加了接入链路带宽（非常昂贵！）

b. 安装本地缓存

假设

平均对象大小 = 100kb
机构内浏览器对原始服务器的平均请求率为 = 15请求/s
平均到浏览器的速率：1.5Mbps
机构内部路由器到原始服务器再返回到路由器的的延时（Internet 延时）= 2s
接入链路带宽：1.54Mbps

结果

LAN 利用率: 15%
接入网络利用率：？
总体延迟= ? 代价: web缓存(廉价!)

计算链路利用率，有缓存的延迟：

假设

缓存命中率0.4：40%请求在缓存中被满足，其他60%的请求需要被原始服务器满足
接入链路利用率: 60%的请求采用接入链路
进过接入链路到达浏览器的数据速率 = 0.6*1.50 Mbps = 0.9 Mbps
利用率= 0.9/1.54 = 0.58
总体延迟 = 0.6 * (从原始服务器获取对象的延迟，也就是接入延时 + Internet延时) +0.4 * (从缓存获取对象的延迟，也就是LAN延时) = 0.6 * (2s) + 0.4 * (msecs，这个很小，所以几乎不看了) = 1.2 secs
比安装154Mbps链路还来得小 (而且比较便宜!)

(4) 缓存与服务器一致性问题

如果服务器中的文件修改了，那么缓存需要向服务器请求新的内容

条件GET方法

条件GET方法（对象版本和服务器版本一致性问题）

目标：如果缓存器中的对象拷贝是最新的，就不要发送对象
缓存器: 在HTTP请求中指定缓存拷贝的日期 If-modified-since:<date>
服务器: 如果缓存拷贝陈旧，则响应报文没包含对象: HTTP/1.0 304 Not Modified

2.3 FTP协议

现在分享文件多使用云盘之类的，FTP是早期的文件分享应用

2.3.1 基本信息

FTP: 文件传输协议

项目	说明
用处	向远程主机上传输文件或从远程主机接收文件
网络架构	客户/服务器模式客户端：发起传输的一方；服务器：远程主机
协议	ftp: RFC 959
端口号	ftp服务器：端口号为21

2.3.2 流程

FTP: 控制连接与数据连接分开

控制连接

FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
客户端通过控制连接获得身份确认
客户端通过控制连接发送命令浏览远程目录（或者其他信息）

数据连接

服务端收到一个文件传输命令时，服务器打开一个到客户端的数据连接
一个文件传输完成后，服务器关闭连接

继续控制连接

客户端继续通过控制连接发送命令：下载文件

重新开启数据连接

服务器打开第二个TCP 数据连接用来传输另一个文件（服务器主动）
然后又关闭连接

客户端向服务端发送并保持控制连接，通过控制连接来向服务端发送命令

服务端接受命令之后，向客户端请求建立数据连接，通过数据连接来发送文件

控制连接：带外（ “out of band” ）传送，就是服务端可以向客户端发送请求建立连接
FTP服务器维护用户的状态信息：当前路径、用户帐户与控制连接对应
FTP是有状态的协议

2.3.3 FTP命令、响应

(1) 命令样例

在控制连接上以ASCII文本方式传送

命令	说明
USER username	发送用户名
PASS password	发送命令
LIST	请服务器返回远程主机当前目录的文件列表
RETR filename	从远程主机的当前目录检索文件 (gets)
STOR filename	向远程主机的当前目录存放文件 (puts)

(2) 返回码示例

状态码	状态信息
331	Username OK, password required
125	data connection already open; transfer starting
425	Can’t open data connection
452	Error writing file

2.3.4 FTP协议 vs HTTP协议

FTP协议是有状态的
FTP协议的控制命令和数据传输分别在两个TCP上进行（HTTP在一个TCP上进行）

2.4 EMail应用 & 相关协议

2.4.1 应用组成

3个主要组成部分

用户代理
邮件服务器
简单邮件传输协议：SMTP

用户代理（客户端软件）

又名 “邮件阅读器” ，用于撰写、编辑和阅读邮件
如Outlook、Foxmail
输出和输入邮件保存在服务器上

Web也有代理，就是浏览器

邮件服务器

邮箱中管理和维护发送给用户的邮件
输出报文队列保持待发送邮件报文
邮件服务器之间的SMTP协议：发送email报文
- 客户：发送方邮件服务器
- 服务器：接收端邮件服务器

2.4.2 SMTP协议

(1) 基本信息

项目	内容
使用协议	TCP
网络架构	C/S
端口号	25

直接传输：从发送方服务器到接收方服务器
传输的3个阶段
- 握手
- 传输报文
- 关闭
命令/响应交互
- 命令：ASCII文本
- 响应：状态码和状态信息
要求：报文必须为7位ASCII码（规范传输内容）

也就是说，邮件的内容也必须在7位ASCII码之内，最开始连中文也不能传输；后来有了补丁才可以

(2) 流程

① 邮件发送流程

举例：Alice给Bob发送报文

Alice使用用户代理撰写邮件并发送给 bob@someschool.edu
Alice的用户代理将邮件发送到她的邮件服务器；邮件放在报文队列中
SMTP的客户端打开到Bob邮件服务器的TCP连接（建立TCP连接）
SMTP客户端通过TCP连接发送Alice的邮件
Bob的邮件服务器将邮件放到Bob的邮箱（POP3，）
Bob调用他的用户代理阅读邮件

② 简单的SMTP交互

以下是两个右键服务器进行SMTP交互的流程

C：客户，发送方邮件服务器
S：服务器，接收方邮件服务器

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr> #邮件来自的邮箱
S: 250 alice@crepes.fr... Sender ok #接受成功
C: RCPT TO: <bob@hamburger.edu> #邮件去往的邮箱
S: 250 bob@hamburger.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

只要按照这个格式就可以在邮件服务器通信，因此可以伪造邮件

(3) SMTP总结

SMTP使用持久连接
SMTP要求报文（首部和主体）为7位ASCII编码
SMTP服务器使用 CRLF.CRLF决定报文的尾部

与HTTP比较：

HTTP：拉（pull）
SMTP：推（push）

HTTP请求是拉取的，SMTP是推送的

二者都是ASCII形式的命令/ 响应交互、状态码
HTTP：每个对象封装在各自的响应报文中（比如如果HTML页面中有链接，并不会将连接和页面都放在一个报文中）
SMTP：多个对象包含在一个报文中（如果传输10张照片，也会放在一个文件中）

可以尝试以下方式发送SMTP协议

telnet servername 25
see 220 reply from server
enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands

2.4.3 邮件报文格式

(1) 基本格式

SMTP：交换email报文的协议
RFC 822: 文本报文的标准：
首部行：如,
- To:
- From:
- Subject:
主体
- 报文，只能是ASCII码字符

(2) 多媒体扩展

原先只允许使用ASCII码字符，弦子语义扩展

MIME：多媒体邮件扩展（multimedia mail extension）, RFC 2045, 2056
在报文首部用额外的行申明MIME内容类型

常用Base64 对STMP的ASCII码进行拓展传输更多内容

Base64 常用于在处理文本数据的场合，表示、传输、存储一些二进制数据，包括 MIME 的电子邮件及 XML 的一些复杂数据。

在 MIME 格式的电子邮件中，base64 可以用来将二进制的字节序列数据编码成 ASCII 字符序列构成的文本。

2.4.4 邮件访问协议

邮件访问协议就是用户代理从邮件服务器拉取邮件

两推一拉

SMTP: 传送到接收方的邮件服务器
邮件访问协议：从服务器访问邮件（3种方式）

POP3：邮局访问协议（Post Office Protocol）[RFC 1939]

用户身份确认 (代理<-->服务器) 并下载
IMAP：Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]

更多特性和功能 (更复杂) ；在服务器上处理存储的报文
HTTP：Hotmail , Yahoo! Mail等；方便

(1) POP3协议

用户确认阶段

客户端命令：
- user: 申明用户名
- pass: 口令
服务器响应
- +OK
- -ERR

事物处理阶段

客户端
- list: 报文号列表
- retr: 根据报文号检索报文
- dele: 删除
- quit：关闭连接

# 用户确认阶段
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on
# 事物处理阶段
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off

先前的例子使用 “下载并删除”模式。

如果改变客户机，Bob不能阅读邮件
“下载并保留”：不同客户机上为报文的拷贝
POP3在会话中是无状态的

下载并删除模式：假如Bob在手机上下载，那么在电脑上就看不到这封右键了

(2) IMAP协议

IMAP服务器将每个报文与一个文件夹联系起来
允许用户用目录来组织报文
允许用户读取报文组件
IMAP在会话过程中保留用户状态：
- 目录名、报文ID与目录名之间映射

2.5 DNS应用

DNS(Domain Name System)，域名解析系统

从域名到IP地址的转换（主要功能）

DNS并不是给人使用的应用，而是给应用使用的应用

DNS是一种基础设施，与后文的CDN一样

2.5.1 DNS的出现和目的

首先要记住，DNS使用的是UDP协议

(1) DNS的历史

ARPANET的名字解析解决方案
- 主机名：没有层次的一个字符串（一个平面）
- 存在着一个（集中）维护站：维护着一张主机名-IP地址的映射文件：Hosts.txt
- 每台主机定时从维护站取文件
ARPANET解决方案的问题
- 当网络中主机数量很大时
- 没有层次的主机名称很难分配

(2) DNS的必要性

IP地址标识主机、路由器
但IP地址不好记忆，不便人类使用(没有意义)
人类一般倾向于使用一些有意义的字符串来标识 Internet上的设备，例如：qzheng@ustc.edu.cn 所在的邮件服务器 www.ustc.edu.cn 所在的web服务器
存在着“字符串”—IP地址的转换的必要性
人类用户提供要访问机器的“字符串”名称
由DNS负责转换成为二进制的网络地址

(3) DNS需要解决的问题

DNS系统需要解决的问题

问题1：如何命名设备
- 用有意义的字符串：好记，便于人类用使用
- 解决一个平面命名的重名问题：层次化命名
问题2：如何完成名字到IP地址的转换
- 分布式的数据库维护和响应名字查询
  
  （因为一台设备是做不了的，IoT时代更是有上千亿台设备）
问题3：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作

总的来说就是

怎么命名
怎么解析（转换）
怎么维护

(4) DNS的总体思路和目标

① 总体思路

DNS的主要思路

分层的、基于域的命名机制
若干分布式的数据库完成名字到IP地址的转换
运行在UDP之上端口号为53的应用服务

运行在UDP上：事务型的请求，发出请求响应ip就行了

DNS是核心的Internet功能，但以应用层协议实现
在网络边缘处理复杂性（互联网最核心的功能（DNS）在边缘系统实现的）

② 主要目的

DNS主要目的：

实现主机名-IP地址的转换(name/IP translate) （主要功能）

其它目的

主机别名到规范名字的转换：Host aliasing
邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing，然后由邮件服务器的正规地址获取ip
负载均衡：Load Distribution（分配具体的服务器提供服务）

比如www.ibm.com，IBM的服务器不可能只有一条，实际上有很多台的服务器支撑，不过它们的别名都是ibm，在dns中首先要转换成真实的名字

下面围绕DNS要解决的问题逐一展开讲解

2.5.2 DNS命名

名字空间(The DNS Name Space)

(1) 域名结构：层次树

DNS域名结构

一个层面命名设备会有很多重名
DNS采用层次树状结构的命名方法
Internet 根被划为几百个顶级域(top lever domains)
- 通用的(generic) .com; .edu ; .gov ; .int ; .mil ; .net ; .org .firm ; .hsop ; .web ; .arts ; .rec ;
- 国家的(countries) .cn ; .us ; .nl ; .jp
每个(子)域下面可划分为若干子域(subdomains)
树叶是主机
查询的时候就会从根服务器依次往下查询

某些域名可以管子啊顶级域下面的子域，或者直接挂在顶级域上
比如 ibm.com，直接挂在了com顶级域上，比如美国的政府直接挂在gov上面

命名设备的时候从树叶往树根走，比如www.baidu.com
对域命名，从树枝走，而不是树叶，比如中国教育网的域名为 edu.cn

(3) DNS名字空间

DNS名字空间(The DNS Name Space)

域名(Domain Name)

从本域往上，直到树根
中间使用“.”间隔不同的级别
例如：ustc.edu.cn、auto.ustc.edu.cn、www.auto.ustc.edu.cn
域的域名：可以用于表示一个域

主机的域名：一个域上的一个主机

域名的管理

一个域管理其下的子域

.jp 被划分为 ac.jp co.jp；.cn 被划分为 edu.cn com.cn

创建一个新的域，必须征得它所属域的同意

域与物理网络无关
- 域遵从组织界限，而不是物理网络
  - 一个域的主机可以不在一个网络
  - 一个网络的主机不一定在一个域
- 域的划分是逻辑的，而不是物理的

网络的划分是物理的

(2) 根名字服务器

树之后一个根，可靠性较低
根服务器有多台，提高了可靠性和查询效率
全球有13个根服务器，但是中国大陆没有
当一个服务器崩了，可以到其他服务器查询
根≠顶级域，顶级域是根下面的一级

2.5.3 DNS域名解析

一个名字服务器的问题
- 可靠性问题：单点故障
- 扩展性问题：通信容量
- 维护问题：远距离的集中式数据库

(1) 域名区域Zone

解决这些问题，可以将树划分成若干个区域

区域(zone)
- 区域的划分有区域管理者自己决定
- 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分

划分成多台服务器可以有效解决可靠性、扩展性、维护问题

区域划分如下

如图，耶鲁大学的cs科目单独划分成一个区域管理

隐含着条件：上层的区域知道下层的区域怎么走

(2) 区域名字服务器

名字服务器：
- 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息 (authoritative record) （名字→ip的转换）
- 名字服务器允许被放置在区域之外，以保障可靠性
权威DNS服务器
- 组织机构的DNS服务器，提供组织机构服务器（如 Web和mail）可访问的主机和IP之间的映射
- 组织机构可以选择实现自己维护或由某个服务提供商来维护
顶级域(TLD)服务器

负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）

Network solutions 公司维护com TLD服务器

Educause公司维护edu TLD服务器

(3) 服务器维护记录的格式

每个区域的权威服务器要维护一个如下的数据库

资源记录(resource records)

作用：维护域名-IP地址(其它)的映射关系
位置：Name Server的分布式数据库中

不仅是域名-IP地址的映射，还包括别名的映射，邮件地址到真实域名的映射等

下面是记录的格式

RR格式: (domain_name, ttl, type,class,Value)

项目	说明	说明
Domain_name	域名
Ttl: time to live	生存时间，就是某个资源记录插入到表当中，生存时间是多少；根据Ttl是否无穷大，记录划分为权威记录和缓冲记录	如果Ttl很大，为无穷大，说明这个记录是该区域服务器应该维护的记录，也就是这个记录就在这个服务器内；如果Ttl为有限值，说明这个记录是该区域服务器访问别的区域服务器的时候取出来的记录暂时缓存到本地的记录，下次查询的时候就直接从本地拿，当Ttl结束的时候，就会删除这个记录缓冲是为了性能，删除是为了一致性 Ttl默认是2天
Class类别	对于Internet，值为IN	对于互联网之外的其他网络，有其他的值；可见DNS不仅仅为了Internet；但是我们现在只研究Internet，所以只有IN的值
Value	可以是数字，域名或ASCII串	域名对应的ip地址
Type类别	资源记录的类型	域名解析系统除了域名→IP的转换，还包括其他业务，通过Type划分，见下方表格

Type类型	Name的含义	Value的含义	举例
A	主机	ip地址
CNAME	别名	规范名字	www.ibm.com的规范名字为servereast.backup2.ibm.com
NS	域名(如foo.com)	该域名的权威服务器的名字	NAME仅仅具体到了域名，还没有到主机
MX	邮件	name对应的邮件服务器的名字

一个例子

(4) DNS工作原理

① 工作流程

应用(application)调用解析器(resolver)
解析器作为客户向Name Server发出查询报文（封装在UDP段中）
Name Server返回响应报文(name/ip)

解析器resolver如何知道local name server在哪？要配置

一台设备上网必备的IP信息

我的IP地址

我的子网掩码

我的local name serve

我的default getway（路由器）（也就是我处于这个子网，要出去要找哪个路由器）

要么手工配置，要么通过DHCP协议自动配置

一般指定在子网内部的服务器，因为快

② 本地名字服务器

本地名字服务器（Local Name Server）

并不严格属于层次结构
每个ISP (居民区的ISP、公司、大学）都有一个本地DNS服务器
也称为“默认名字服务器”
当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器
起着代理的作用，将查询转发到层次结构中

③ 名字服务器解析过程

名字服务器(Name Server)

本地名字服务器就是名字服务器，只不过对于客户来说是默认查询的服务器，一般设置为一个子网当中的

名字解析过程

如果目标名字在Local Name Server中，有两种可能
- 情况1：查询的名字在该区域内部
- 情况2：缓存(cashing)
此时直接返回ip

当与本地名字服务器不能解析名字时，联系根名字服务器（全球有13个根服务器），顺着根-TLD 一直找到权威名字服务器

a. 递归查询

递归查询

本地DNS服务器找到根DNS服务器之后，根DNS服务器一直往下找到权威DNS服务器，再将结果返回给根DNS服务器，再返回给本地DNS服务器

缺点

名字解析负担都放在当前联络的名字服务器上
问题：根服务器的负担太重
解决：迭代查询 (iterated queries)

b. 迭代查询

主机cis.poly.edu 想知道主机 gaia.cs.umass.edu 的IP地址

根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址
最后由权威名字服务器给出解析结果
当前联络的服务器给出可以联系的服务器的名字
“我不知道这个名字，但可以向这个服务器请求

最终记住，缓存是为了效率，删除是为了一致性

(5) DNS协议报文

DNS协议：查询和响应报文的报文格式相同

通过ID来判断请求和响应是对应的，否则只能串行地请求响应
flag来判断返回内容的类型

(6) 缓存的作用

提高性能：缓存

一旦名字服务器学到了一个映射，就将该映射缓存起来
根服务器通常都在本地服务器中缓存着，使得根服务器不用经常被访问
目的：提高效率
可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致
解决方案：TTL（默认2天）

总之缓存是为了效率，删除是为了一致性

2.5.4 DNS维护(CRUD)

这里以添加为例，删改查是一样的

在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
（Type = NS、 Type = A 相当于指针）
在新增子域的名字服务器上运行名字服务器，负责本域的名字解析:名字->IP地址

例子:在com域中建立一个“Network Utopia”

到注册登记机构注册域名networkutopia.com
- 需要向该机构提供权威DNS服务器（基本的、和辅助的）的名字和IP地址
- 登记机构在com TLD服务器中插入两条RR记录:
  
  (networkutopia.com,dns1.networkutopia.com,NS )
  
  (dns1.networkutopia.com,212.212.212.1,A)
在networkutopia.com的权威服务器中确保有
- 用于Web服务器的www.networkuptopia.com的类型为A的记录
- 用于邮件服务器mail.networkutopia.com的类型为MX的记录

2.5.5 攻击DNS

本节讲解攻击DNS的手段，但是总的来说，DNS还是比较健壮的

教材对于域名解析系统攻击比较详细的

(1) DDoS 攻击

对根服务器进行流量轰炸攻击：发送大量ping

没有成功
原因１：根目录服务器配置了流量过滤器，防火墙
原因２：Local DNS 服务器缓存了TLD服务器的IP地址, 因此无需查询根服务器

就是因为服务器是分布式的，轰炸轰不过来，不一定所有的查询都需要走跟服务的，TLD服务器可能都进行了缓存了

向TLD服务器流量轰炸攻击：发送大量查询

可能更危险
效果一般，大部分DNS缓存了TLD

(2) 重定向攻击

中间人攻击
- 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点
DNS中毒
- 发送伪造的应答给DNS服务器，希望它能够缓存这个虚假的结果
技术上较困难：分布式截获和伪造

(3) 利用DNS基础设施进行DDoS

伪造某个IP进行查询，攻击这个目标IP
查询放大，响应报文比查询报文大
效果有限

2.6 P2P架构(非结构化)

CS的问题：可靠性差、可扩展性差等

P2P的特点就是，一个主机，既可以是服务器，又可以是客户端

随着用户的增加，客户也在增加，因此很容易能扩展（可扩展性强）

分布式（可靠性强）

没有（或极少）一直运行的服务器
任意端系统都可以直接通信
利用peer的服务能力
Peer节点间歇上网，每次IP 地址都有可能变化

例子:

文件分发 (BitTorrent)
流媒体(KanKan)
VoIP (Skype)

2.6.1 C/S vs P2P(以文件分发为例)

问题: 从一台服务器分发文件（大小F）到N个peer 需要多少时间？

服务器将文件分给客户的时候，对于每一个客户都需要上载一份拷贝到网络中

如图，主要还是考虑网络的压力
文件的大小是F

文件分发时间: C/S模式

服务器传输：都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝（到网络中）:

发送一个copy: F/us（上载）→ 发送N个copy： NF/us （上载）

客户端: 每个客户端必须下载一个文件拷贝

dmin = 客户端最小的下载速率
下载带宽最小的客户端下载的时间：F/d_min （下载），这个也是客户端下载需要花费的最大的时间

采用C-S方法将一个F大小的文件分发给N个客户端耗时D_c-s的数值如下(此时求的是最少的时间)

D_c-s ≥ max{NF/u_s（随着N线性增长）,F/d_min}

NF/u_s是上载的时间
F/d_min是下载的时间
最终当N主键增大的时候，所需要的时间也会增多，因为上载的数量也会增多，d_min的影响忽略不计了

文件分发时间: P2P模式

这里假设有一个服务器

服务器传输：最少需要上载一份拷贝

发送一个拷贝的时间：F/u_s（上载）

客户端: 每个客户端必须下载一个拷贝

最小下载带宽客户单耗时: F/dmin（下载）

客户端: 所有客户端总体下载量NF

最大上载带宽是：u_s（服务器的） + ∑u_i（所有客户端的）（上载）
除了服务器可以上载，其他所有的peer节点都可以上载

采用P2P方法将一个F大小的文件分发给N个客户端耗时

D_p2p ≥ max{F/u_s,F/d_min,NF/(u_s + ∑u_i)}

可以看到，上载和下载都有影响
NF/(u_s + ∑u_i)分子随着N线性变化，每个节点需要下载，整体下载量随着N增大；分母也是如此,随着peer节点的增多，每个peer也带了服务能力

C-S 线性
P2P
- 非线性，性能高，可拓展性强
- 难管理（动态性强，很多数据都是不确定的）

接下来讲讲P2P模式的管理/运行方式

概念：覆盖网络

首先有一个概念，Peer和Peer在应用层会构成一个逻辑上的覆盖网络(overlay)，仅仅是逻辑上的，但是在物理上是会经过很多次路由等

覆盖网络是一个图

如果X和Y之间有一个 TCP连接，则二者之间存在一条边

所有活动的对等方和边就是覆盖网络

边并不是物理链路

给定一个对等方，通常所连接的节点少于10个

非结构化P2P：构成的overlay是任意的
- 集中化目录
DHT 结构化P2P
- overlay的是有结果的，比如环形、树等，节点哈希内容哈希按一定规律存内容

下面主要讲解非结构化P2P，结构化在高级课中讲解

场景:P2P文件共享

本章用P2P文件共享来展示P2P

例子

Alice在其笔记本电脑上运行P2P客户端程序
间歇性地连接到 Internet，每次从其 ISP得到新的IP地址
请求“双截棍.MP3”
应用程序显示其他有“ 双截棍.MP3” 拷贝的对等方
Alice选择其中一个对等方，如Bob.
文件从Bob’s PC传送到 Alice的笔记本上：HTTP
当Alice下载时，其他用户也可以从Alice处下载
Alice的对等方既是一个Web 客户端，也是一个瞬时Web 服务器

所有的对等方都是服务器 = 可扩展性好！

两大问题

如何定位所需资源（就是找到哪个对等体拥有该资源）
如何处理对等方的加入与离开

2.6.2 集中式目录(如Napster)

一个集中的服务器记录每个客户端的信息（当然是客户向服务器注册的信息）

客户端可以到集中化目录查询其他客户端的信息

查询到结构之后再与要连接的peer建立连接

最初的“Napster”设计就是这个架构

当对等方连接时，它告知中心服务器：

IP地址
内容

Alice查询 “双截棍 .MP3” ，服务器返回Bob拥有这个文件
Alice从Bob处请求文件

缺点：

单点故障（目录服务器崩了）
性能瓶颈（目录服务器会成为性能的瓶颈）
侵犯版权

文件传输是分散的，而定位内容则是高度集中的

2.6.3 完全分布式(泛洪查询Gnutella)

查询洪泛：Gnutella（完全分布式）

全分布式（没有中心服务器）
开放文件共享协议(开放的，所有人都可以下载)
许多Gnutella客户端实现了Gnutella协议（类似HTTP有许多的浏览器）

(1) 泛洪查询流程

首先是查询方法

在已有的TCP连接上发送查询报文
对等方转发查询报文
以反方向返回查询命中报文

总之还是建立TCP连接

前提在各个节点之间已经形成了覆盖网络

此时我要查询一个文件

我的客户端向所有邻居发出查询
所有邻居的客户端向其邻居发出查询
拥有资源的节点通过反向的方法将查询的结果发回来

我的客户端就知道那个节点有资源（解决目录的问题）
再向拥有资源的节点发出请求，得到资源

解决目录的方式就是泛洪查询

问题就是

如果一直查询，查不到，甚至最终形成一个环
- 设置TTL，有限地跳转
- 中转节点记录状态，当再次接受到请求的时候不转发
可扩展性问题，如何建立网络

(2) 如何建立网络

上面假设前提是已经建立了网络，但是网络是如何建立的呢？

Gnutella：对等方加入（网络的建立）

对等方X必须首先发现某些已经在覆盖网络中的其他对等方：使用可用对等方列表自己维持一张对等方列表（经常开机的对等方的IP、死党列表）联系维持列表的Gnutella站点

（在安装客户端的时候就会得到一张列表）
X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接
X向Y发送一个Ping报文，Y向所有的邻居转发该Ping报文
所有收到Ping报文的对等方以Pong报文响应 IP地址、共享文件的数量及总字节数
X收到许多Pong报文，然后随机地挑选节点与其建立TCP连接

如果对等方X离开呢？

节点X向所有邻居发消息要离开
所有的邻居都重新找一个节点连接来补充X，以满足图查找所需要的度

(3) 现状

理论上很好，但是技术上难以实现（也有非技术原因）
之所以开源就是因为找不到东西，没人用

2.6.4 混合体(KaZaA)

(1) 查询大致流程

每个对等方要么是一个组长，要么隶属于一个组长

对等方与其组长之间有 TCP连接
组长对之间有TCP连接

组长跟踪其所有的孩子的内容，组长与其他组长联系

转发查询到其他组长
获得其他组长的数据拷贝

小组内部查询是集中式查询，组长和组长之间就是完全分布式查询

某一个对等体要查询，先向组长查询目录（查询谁有这个内容），如果组长知道，就直接返回；如果不知道，就向其他组长查询

(2) KaZaA：查询

文件的结构：每个文件有一个散列标识码（唯一Hash，上载时赋予）和一个描述符（描述信息，用户在检索的时候匹配描述）
- 文件本身
- 文件描述符（描述文件内容的，搜索的时候就通过文件描述符匹配）
- 散列标识码（唯一Hash，上载时赋予，用于唯一表示一个文件）
客户端向其组长发送关键字查询，组长用匹配（描述）进行响应：
- 对每个匹配：元数据、散列标识码和IP地址
如果组长将查询转发给其他组长，其他组长也以匹配进行响应
客户端选择要下载的文件
- 向拥有文件的对等方发送一个带散列标识码的 HTTP请求

(3) KazaA小技巧

请求排队

限制并行上载的数量
确保每个被传输的文件从上载节点接收一定量的带宽

激励优先权

鼓励用户上载文件
加强系统的扩展性

并行下载

从多个对等方下载同一个文件的不同部分
- HTTP的字节范围首部
- 更快地检索一个文件

Distributed Hash Table (DHT)

 哈希表  DHT方案  环形DHT 以及覆盖网络  Peer波动

2.6.5 案例:文件分发 BitTorrent

Peer可能会变换用于交换块的peer节点
扰动churn: peer节点可能会上线或者下线
一旦一个peer拥有整个文件（种子），它会（自私的）离开或者保留（利他主义）在torrent中

(1) 前提

目的：建立一个互通有无的学习小组，

文件被分为一个个块256KB，每一个节点拥有一些块，但并不拥有所有的块
拥有一个文件所有块的称为种子，一个块都没有的称为吸血鬼

(2) 目录查询(定位资源)

每个节点有一个bit map（hash），用map标记是否具备，有则标识为1否则为0

假如文件被分成了16块，那么就有一个长度为16位的信息，每一位表示一个块，0表示该节点没有对应的块，1表示有这个块
节点之间通过泛洪来转法各自的bit map，这样每个节点就知道哪个节点有哪些块了，然后就可以向对应的节点发出请求查询这些块了
bit map会定期交换，让所有节点实时知道每一个节点拥有块的情况

bit map全是0的是吸血鬼，全是1的是种子

(3) 请求文件块

在任何给定时间，不同 peer节点拥有一个文件块的子集
周期性的，Alice节点向邻居询问他们拥有哪些块的信息
Alice向peer节点请求它希望的块，稀缺的块（稀缺优先，对集体有利）

（集体提出）客户端优先请求稀缺的（稀缺优先，对集体有利）
（集体定的规则）优先向提供服务好的客户端服务（个人利益与集体利益绑定）
（造成个人遵守）客户端优先请求稀缺的（利他等于利己）

在任何给定时间，不同peer节点拥有一个文件块的子集
周期性的，Alice节点向邻居询问他们拥有哪些块的信息
Alice向peer节点请求它希望的块，稀缺的块（稀缺优先）

当一个节点加入时，这个节点是一个吸血鬼
然后随机地请求四个块（bit map有4位置1）
然后请求在洪流当中比较稀缺的块（稀缺优先）

稀缺优先

稀缺优先的好处：

对于整个洪流来说，稀缺的块得以补齐，就不再稀缺了

具有稀缺块的节点如果下线之后，洪流中仍然具有这个稀缺块

这对于集体的利益是有好处的

集体利益如何与个人利益捆绑

自己请求的时候请求稀缺的节点，当自己成为服务提供者的时候，优先向向自己服务好的服务

当自己拿到稀缺块的时候，自己被其他节点请求的概率就会增加，自己就会向别的节点提供更多的服务

这样自己请求块的时候其他人就会向自己提供更好的服务

一开始为什么不找稀缺的块，而是先随机找4个块呢？

稀缺的块肯定稀缺，向有稀缺块的节点发出的请求就很多，吸血鬼拿到稀缺块的时间可能就很长，在那么长的时间内无法向别人提供服务，别人也就无法向别人提供很好的服务
然后请求稀缺块，别人向他请求的概率就大，别人就向他提供更好的服务

种子可能离开洪流，也可能继续留在洪流

离开洪流，那么下次请求服务的时候可能速度比较慢
否则，之后下载的时候就比较快

在使用迅雷之类的P2P文件共享软件的时候，上载设置为0对自己并不是很好：向其他节点提供的带宽越小，其他节点给自己的带宽就越小

(4) 发送文件块: tit-for-tat

一报还一报

Alice向4个peer发送块，这些块向它自己提供最大带宽的服务
- 其他peer被Alice阻塞 (将不会从Alice处获得服务)
- 每10秒（每个周期10秒）重新评估（谁对它好）一次：前4位
每过30秒（也就是第三个周期）：随机选择其他peer 节点，向这个节点发送块
- “优化疏通” 这个节点
- 新选择的节点可以加入这个top 4

下面用通俗的话来说一下

当自己拥有了一些块
当来了一些请求之后，并不是将带宽平分给这些请求
假设有80个请求，那么只服务4个，即与这4个建立连接，疏通四个请求（有限疏通）
剩下的76个并不是先来先得，而是每个周期都进行一次排序
- 第一个周期和第二个周期：评估谁对自己好，也就是谁曾经提供给自己的带宽大，字节数量多，就排到前面
- 第三个周期：随机选，没准有一个黑马，选择了他，向其提供更好的服务，就是做一些试探

好处：

更高的上载速率：发现更好的交易伙伴，获得更快的文件传输速率!

(5) 如何处理节点的加入

bit网络怎么加入洪流中的：带外解决（out of band）

有一些文件检索的bit网站，然后在覆盖网络中根据描述符匹配，得到hash，试图下载文件

文件在上载的时候会有：文件本身，描述符，hash

对于这个torrent文件，会给出包括这个资源文件的tracker server，里面有哪些tracker server（跟踪服务区），tracker server维护者某个文件由哪些节点在维护
bit客户端向tracker server说明要加入到这个洪流中
然后tracker server给客户端一个peer的列表

下面用简单的话说明一下

就是通过搜索引擎，下载torrent文件，torrent文件中包括了关于这个文件的tracking server
tracking server维护者关于这个文件的peer
客户端发出请求，加入洪流
tracking server给出peer的列表
客户端可以和这些peer构成洪流

当一个节点加入时，这个节点是一个吸血鬼
然后随机地请求四个块（bit map有4位置1）
然后请求在洪流当中比较稀缺的块（稀缺优先）

2.6.6 结构化P2P

环装的覆盖网络等
...

这部分了解即可

2.7 CDN

视频流化服务和CDN：上下文

2.7.1 背景

视频流量：占据着互联网大部分的带宽
- Netflix, YouTube: 占据37%, 16% 的ISP下行流量
- 大约1B YouTube 用户, 大约75M Netflix用户
挑战：
- 规模大：如何给这么多的用户并行提供服务，且单个超级服务器无法提供服务
- 易购性：不同用户拥有不同的能力（例如：有线接入和移动用户；带宽丰富和受限用户）

解决方案: 分布式的，应用层面的基础设施

2.7.2 多媒体：视频

视频：固定速度显示的图像序列（由于人的视觉效应，图片快速的切换就形成了视频）

e.g. 24 images/sec（表示每秒24章图片）

网络视频特点：

高码率：>10x于音频,高的网络带宽需求
可以被压缩（视频一定是被压缩后传输的，完整地传输视频不大可能）
90%以上的网络流量是视频
视频可以看做数字化图像：每个图片都是像素的阵列，即每个像素被若干bits表示

编码：使用图像内和图像间的冗余来降低编码的比特数

空间冗余(图像内，比如某一个图形的某一块都是相同的色素)
时间冗余(相邻的图像间，比如相邻的图像之间某几个相同的位置使用相同的色素，可以说这个色素持续了多长时间)

编码方案：

CBR: (constant bit rate): 以固定速率编码

VBR: (variable bit rate): 视频编码速率随时间的变化而变化

如：

MPEG 1 (CD-ROM) 1.5Mbps
MPEG2 (DVD) 3-6 Mbps
MPEG4 (often used in Internet, < 1 Mbps)

2.7.3 多媒体流化服务:DASH

看视频时不是先全部下载之后再看，而是服务端一边传输，客户端一边看，并行工作

DASH: Dynamic, Adaptive Streaming over HTTP 动态自适应

这是建立在http协议上的

http不仅可以用于web，还可以用于文件上下载(比如email应用中下载邮件可以用http)，或者是音视频的播放

DASH解决的是异构性问题

服务器:

将视频文件分割成多个块（流化），每个块都可以支持若干秒的播放
每个块独立存储（就是存储到不同的服务器中），编码于不同码率（8-10种，也就是每个块都有不同的清晰度）
每个文件都有一个告示文件，用来存储这个文件分别有哪些块，顺序是多少，清晰度是多少，在哪个服务器中等

告示文件（manifest file）: 提供不同块的URL（自适应：自己选择）

客户端:

先获取告示文件
周期性地测量服务器到客户端的带宽
查询告示文件,在一个时刻请求一个块，HTTP头部指定字节范围
- 如果带宽足够，选择最大码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)

也就是在播放的时候，就可以请求后面的块了

根据综合因素考虑要请求哪个块

比如带宽足够，选择最大码率的视频块

以及根据设备的需求来自适应选择块

“智能”客户端: 客户端自适应决定

什么时候去请求块 (不至于缓存挨饿，或者溢出)
请求什么编码速率的视频块 (当带宽够用时，请求高质量的视频块)
哪里去请求块 (可以向离自己近的服务器发送URL，或者向高可用带宽的服务器请求)

2.7.4 CDN

挑战:

上述方法只是请求一个或者少数结果服务器

服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)

服务器可以优化自身能力(比如带宽等)，但是无法优化网络(链路)

(1) 单个服务器的问题

服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
“二八规律”决定了网络同时充斥着同一个视频的多个拷贝（重复流量），效率低（付费高、带宽浪费、效果差）
单点故障点，性能瓶颈
周边网络的拥塞

(2) CDN介绍

① 原理

CDN（content distribution network）

通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验（内容加速服务）

CDN运营商（国内国外都有运营商，比如国外的Akamai，中国蓝汛）在全网部署缓存节点cache server

ICP购买运营商的服务，将自己的视频缓存到cache节点中

客户端在请求的时候，通过DNS，映射到离自己最近的，速度最快的cache

② 部署节点选择

但是CDN如何部署节点呢？

enter deep: 将CDN服务器深入到许多接入网（local ISP）
- 优点：更接近用户，跳数比较少，拥塞情况比较好，提供的服务质量比较高
- 缺点：数量多，离用户近，管理困难
- Akamai, 1700个位置

bring home: 部署在少数(10个左右)关键位置（上层位置，到用户的跳数较多），如将服务器簇安装于POP附近（离若干1stISP POP较近）
- 这些关键位置离数据中心机房比较近，但是提供的服务还是比较好
- 采用租用线路将服务器簇连接起来
- Limelight

来看Netflix的例子

Netflix先购买了Akamai的服务
然后在cache的节点上部署了视频的缓存
客户先从原服务器获取manifest file，然后根据manifest file自适应选择块
如果网络路径拥塞，可能选择不同的拷贝（DNS也可以通过请求重定向来选择cache server）

互联网络主机-主机之间的通信作为一种服务向用户提供

(3) OTT 挑战

OTT：over the top

CDN运行在网络层次比较高的应用层，而且是在接入网

一般来说，提高效率应该考虑的是底层，比如网络核心，但是在计算机网络中，网络核心仅仅提供最基本的服务，提高效率都是在顶层提供

在拥塞的互联网上复制内容

OTT(互联网公司越过运营商，发展基于开放互联网的各种视频及数据服务业务)，over the top

从哪个CDN节点中获取内容？
用户在网络拥塞时的行为？
在哪些CDN节点中存储什么内容？

(4) 场景举例

① 简单场景

简单内容访问场景

Bob(客户端)请求视频http://netcinema.com/6Y7B23V
视频存储在CDN，位于http://KingCDN.com/NetC6y&B23V
下图中的authorative是权威服务器

3的内容是 netcinema;s DNS returns URL:http://netcinema.com/6Y7B23V

② Netflix案例

注册账户还是要到原服务器注册
网飞将网页上传到了Amazon cloud上面

2.8 Socket套接字编程

Socket编程：应用进程使用传输层提供的服务能够交换报文，实现应用协议，实现应用
TCP/IP：应用进程使用Socket API访问传输服务
地点：界面上的SAP(Socket）
方式：Socket API
目标: 学习如何构建能借助sockets进行通信的C/S应用程序

socket: 分布式应用进程之间的门，传输层协议提供的端到端服务接口

2种传输层服务的socket类型:

TCP: 可靠的、字节流的服务
UDP: 不可靠（数据UDP数据报）服务

套接字：应用进程与端到端传输协议（TCP或UDP）之间的门户
TCP服务：从一个进程向另一个进程可靠地传输字节流

2.8.1 TCP 套接字编程

(1) 逻辑流程

服务器首先运行，等待连接建立

服务器进程必须先处于运行状态
1. 创建欢迎socket（可以理解为监听socket）
2. 和本地端口捆绑
3. 在欢迎socket上阻塞式等待接收用户的连接

客户端主动和服务器建立连接：

创建客户端本地套接字（隐式捆绑到本地port）
- 指定服务器进程的IP地址和端口号，与服务器进程连接
当与客户端连接请求到来时
- 服务器接受来自用户端的请求，解除阻塞式等待，返回一个新的socket（connect socket，与欢迎socket不一样，但是与客户端进行捆绑），与客户端通信，同时欢迎socket解除阻塞
- 允许服务器与多个客户端通信
- 使用源IP和源端口来区分不同的客户端
连接API调用有效时，客户端P与服务器建立了TCP连接

从应用程序的角度
TCP在客户端和服务器进程之间提供了可靠的、字节流（管道）服务

(2) 相关数据结构

数据结构 sockaddr_in

IP地址和port捆绑关系的数据结构（标示进程的端节点，其实是服务器守护的节点）

struct sockaddr_in {
    short sin_family; //AF_INET
    u_short sin_port; // port
    struct in_addr sin_addr; // IP address, unsigned long
    char sin_zero[8]; // align 校准
};

属性	说明
sin_family	地址簇，这个结构体不仅仅用于IP的通信，还可以用于其他的通信，这里设置为常量AF_INET，表明是TCP/IP的协议簇
sin_port	端口号
sin_addr	ip地址
sin_zero	起对其作用，因为ipx的地址长度比ip的长度，其他地址也是

数据结构 hostent
域名和IP地址的数据结构

struct hostent { 
    char *h_name;	//域名
    char **h_aliases;	//别名
    int h_addrtype;	
    int h_length; //地址长度
    char **h_addr_list;	//IP地址
    #define h_addr h_addr_list[0];
}

属性	类型	说明
h_name	字符串	主机域名
h_aliases	字符串数组	主机的一系列别名
h_addrtype
h_length	数字	地址长度
h_addr_list	字符串数组	ip地址，可以将其复制到sockaddr_in的ip中

作为调用域名解析函数时的参数返回后，将IP地址拷贝到 sockaddr_in的IP地址部分

(3) 代码流程

应用样例

客户端从标准输入装置读取一行字符，发送给服务器
服务器从socket读取字符
服务器将字符转换成大写，然后返回给客户端
客户端从socket中读取一行字符，然后打印出来

实际上，这里描述了C-S之间交互的动作次序

welcomeSocket = socket(...)是创建一个socket值（整数类型），参数就是创建socket的类型，比如TCP，UDP，还可以是IP（因为网络层也给了应用层socket接口）
bind(welcomeSocket, &sad,);这个是将socket与本地的ip和端口捆绑
connectionSocket = accept(welcomeSocket, &cad,…); 在welcomeSocket等待用户建立请求
ClientSocket = socket(PF_INET,…)客户端建立socket，PF_INET表明是TCPsocket，返回的值是整数
客户端不需要显示bind，因为客户端的端口是无所谓的，但是底层也自动选择了端口进行了隐式的捆绑，此时客户端的socket已经有了本地的ip和port
connect(clientSocket, &sad …)这个与服务器建立连接，&sad是服务端的信息
连接建立之后，connectionSocket = accept(welcomeSocket, &cad,…); 会接触阻塞，并返回新的值，新的socket表示的本地ip和port与welcomeSocket是一样的，但是远方的ip和port是客户端的
然后就是send和read了

两个socket的本地ip和port可以一样，并没有影响，因为一个TCP socket需要整个四元组确定的

(4) 代码示例

① 客户端

系统自己默认使用了bind，自动分配

argv[1] 主机的名字 argv[2] 端口号 argv[0] 程序的名字

// client.c
void main(int argc, char *argv[]) {
    // sad表示 server addr
    struct sockaddr_in sad; /* structure to hold an IP address of server */
    int clientSocket; /* socket descriptor */
    struct hostent *ptrh; /* pointer to a host table entry */
    char Sentence[128];
    char modifiedSentence[128];
    //	argv[0]是程序的名字
    host = argv[1]; // argv[1] 表示服务器的域名
    port = atoi(argv[2]); // argv[2]表示服务端的端口
    clientSocket = socket(PF_INET, SOCK_STREAM, 0);
    // 这里底层自动使用了bind

    // sad先清0
    memset((char *)&sad,0,sizeof(sad)); /* clear sockaddr structure */
    sad.sin_family = AF_INET; /* set family to Internet */
    // port先转换成短整形，然后设置成网络次序
    sad.sin_port = htons((u_short)port);
    ptrh = gethostbyname(host);
    /* Convert host name to IP address */
    //将IP地址拷贝到sad.sin_addr
    memcpy(&sad.sin_addr, ptrh->h_addr, ptrh->h_length);
    connect(clientSocket, (struct sockaddr *)&sad, sizeof(sad));

    gets(Sentence); // get input stream from client
    n=write(clientSocket, Sentence, strlen(Sentence)+1); // send line to server
    n=read(clientSocket, modifiedSentence, sizeof(modifiedSentence)); // read line from server
    printf("FROM SERVER: %s\n",modifiedSentence);
    close(clientSocket);  // close the connection
}

② 服务端

// server.c
void main(int argc, char *argv[]) {
    // 只有一个参数，就是服务端的端口号
    struct sockaddr_in sad; /* structure to hold an IP address of server*/
    struct sockaddr_in cad; /*client */
    int welcomeSocket, connectionSocket; /* socket descriptor */
    struct hostent *ptrh; /* pointer to a host table entry */
    char clientSentence[128];
    char capitalizedSentence[128];
    // port
    port = atoi(argv[1]);
    welcomeSocket = socket(PF_INET, SOCK_STREAM, 0);
    memset((char *)&sad,0,sizeof(sad)); /* clear sockaddr structure */
    sad.sin_family = AF_INET; /* set family to Internet */
    sad.sin_addr.s_addr = INADDR_ANY; /* set the local IP address */
    sad.sin_port = htons((u_short)port);/* set the port number */
    // 此处赋值，在表中进行赋值
    bind(welcomeSocket, (struct sockaddr *)&sad, sizeof(sad));
    
    // specify the maximum number of clients that can be queued
    listen(welcomeSocket, 10)
        while(1) {
            connectionSocket=accept(welcomeSocket, (struct sockaddr *)&cad, &alen);
            n=read(connectionSocket, clientSentence, sizeof(clientSentence));
            // capitalize Sentence and store the result in capitalizedSentence
            n=write(connectionSocket, capitalizedSentence, strlen(capitalizedSentence)+1);
            close(connectionSocket);
        }
}

2.8.2 UDP 套接字编程

UDP: 在客户端和服务器之间没有连接

没有握手
发送端在每一个报文中明确地指定目标的IP地址和端口号
服务器必须从收到的分组中提取出发送端的IP地址和端口号

UDP: 传送的数据可能乱序，也可能丢失

进程视角看UDP服务 UDP 为客户端和服务器提供不可靠的字节组的传送服务

(1) 逻辑流程

(2) 代码示例

① 客户端

/* client.c */
void main(int argc, char *argv[])
{
    struct sockaddr_in sad; /* structure to hold an IP address */
    int clientSocket; /* socket descriptor */
    struct hostent *ptrh; /* pointer to a host table entry */
    char Sentence[128];
    char modifiedSentence[128];
    host = argv[1]; port = atoi(argv[2]);
    clientSocket = socket(PF_INET, SOCK_DGRAM, 0);
    /* determine the server's address */
    memset((char *)&sad,0,sizeof(sad)); /* clear sockaddr structure */
    sad.sin_family = AF_INET; /* set family to Internet */
    sad.sin_port = htons((u_short)port);
    ptrh = gethostbyname(host);
    /* Convert host name to IP address */
    memcpy(&sad.sin_addr, ptrh->h_addr, ptrh->h_length);
    gets(Sentence);
    addr_len =sizeof(struct sockaddr);
    n=sendto(clientSocket, Sentence, strlen(Sentence)+1, (struct sockaddr *) &sad, addr_len);
    n=recvfrom(clientSocket, modifiedSentence, sizeof(modifiedSentence),(struct sockaddr *) &sad, &addr_len);
    printf("FROM SERVER: %s\n",modifiedSentence);
    close(clientSocket);
}

② 服务端

/* server.c */
void main(int argc, char *argv[])
{
    struct sockaddr_in sad; /* structure to hold an IP address */
    struct sockaddr_in cad;
    int serverSocket; /* socket descriptor */
    struct hostent *ptrh; /* pointer to a host table entry */
    char clientSentence[128];
    char capitalizedSentence[128];
    port = atoi(argv[1]);
    serverSocket = socket(PF_INET, SOCK_DGRAM, 0);
    memset((char *)&sad,0,sizeof(sad)); /* clear sockaddr structure */
    sad.sin_family = AF_INET; /* set family to Internet */
    sad.sin_addr.s_addr = INADDR_ANY; /* set the local IP address */
    sad.sin_port = htons((u_short)port);/* set the port number */
    bind(serverSocket, (struct sockaddr *)&sad, sizeof(sad));
    while(1) {
        n=recvfrom(serverSocket, clientSentence, sizeof(clientSentence), 0
                   (struct sockaddr *) &cad, &addr_len );
        /* capitalize Sentence and store the result in capitalizedSentence*/
        n=sendto(serverSocket , capitalizedSentence, strlen(capitalizedSentence)+1,
                 (struct sockaddr *) &cad, &addr_len);
    }
}

第2章：小结

应用程序体系结构
- 客户-服务器
- P2P
- 混合
应用程序需要的服务品质描述:
- 可靠性、带宽、延时、安全
Internet传输层服务模式
- 可靠的、面向连接的服务： TCP
- 不可靠的数据报：UDP
流行的应用层协议:
- HTTP
- FTP
- SMTP, POP, IMAP
- DNS
Socket编程

更重要的：学习协议的知识

应用层协议报文类型：请求/响应报文：
- 客户端请求信息或服务
- 服务器以数据、状态码进行响应
报文格式：
- 首部：关于数据信息的字段
- 数据：被交换的信息
控制报文 vs. 数据报文
- 带内（一个TCP传两种报文）、带外（两个TCP）
集中式 vs. 分散式
- 无状态 vs. 维护状态
- 可靠的 vs. 不可靠的报文传输
- 在网络边缘处理复杂性

一个协议定义了在两个或多个通信实体之间交换报文的格式和次序、以及就一条报文传输和接收或其他事件采取的动作

posted @ 2023-07-16 17:32 Crispy·Candy 阅读(129) 评论(0) 编辑收藏举报

刷新页面返回顶部

酥心糖

计算机网络-第二章-应用层

第2章 应用层

2.1 应用层协议原理

2.1.1 网络应用体系结构

(1) 客户-服务器(C/S)

(2) 对等体(P2P)

(3) C/S和P2P混合

(4) 分布式架构

2.1.2 进程通信及问题

(1) 基本概念

(2) 相关问题

(3.1) 进程编址(标识)

(3.2) 应用层向传输层提供的数据

① 提供的数据

② socket

a. TCP socket

b. UDP socket

总结 + 比较

(3.3) 定义应用层协议

应用层协议说明

2.1.3 传输层服务要求

(1) 传输层服务指标

① 指标

② 举例

(2) 传输层提供的服务

① TCP服务

② UDP服务

UDP必要性

(3) 应用举例

(4) 安全TCP(SSL)

应用层应用及协议举例

2.2 Web应用 & HTTP协议

2.2.1 Web应用

(1) Web页面组成

① 组成结构

② URL格式

③ Web页面解析流程

2.2.2 HTTP协议

(1) 基本概念

① HTTP概念

② 连接方式:TCP

③ 往返时间RRT和响应时间

(2) HTTP连接

① 非持久HTTP

a. 介绍

b. 流程举例

c. 维护状态的困难

d. 优缺点

② 持久HTTP

a. 介绍

b. 流水/非流水的持久HTTP

(3) HTTP报文

① HTTP请求报文

a. 请求报文格式

b. 提交表单输入

c. 请求方法类型

② HTTP响应报文

a. 响应报文格式

b. 部分首部行信息

c. 部分状态码

(4) 命令行发送http请求

(5) 用户-服务器状态：cookies

① cookie的组成成分

② cookie流程

③ cookie的应用和原理

④ Cookies与隐私

2.2.3 Web缓存 (代理服务器)

(1) 流程

(2) 优点

(3) 缓存示例

① 相关数据计算

a. 各种延时计算(Internet延时、接入延时、LAN延时)

b. 流量强度和排队延时计算

② 优化方式

a. 提高接入链路带宽

b. 安装本地缓存

(4) 缓存与服务器一致性问题

条件GET方法

2.3 FTP协议

第2章应用层