[A Top-Down Approach][第二章应用层]

2021-12-12 22:37:40

[A Top-Down Approach][第二章应用层]

标签（空格分隔）：未分类

网络应用是计算机网络存在的理由
首先从定义几个关键的应用层概念开始
- 应用程序所需要的网络服务,客户和服务器,进程和运输层接口.
然后详细考察几种网络应用程序.
- Web,电子邮件,DNS,和对等文件分发.
涉及开发运行在TCP和UDP上的应用程序.
- 学习套接字 API
- 浮光掠影的用Python写一些简单的客户-服务器应用程序.

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

应用程序体系结构(application architecture): 由应用程序研发者设计,规定了如何在各种端系统上组织该应用程序.
- 两大主流体系:
  - 客户-服务端体系结构(client-server architecture)
  - 对等(P2P)体系结构(P2P architecture)

客户-服务端体系结构

服务器:有一个总是打开的主机称为服务器,它服务于来自许多其他称为客户的主机.
- 对于某些大型的公司,例如google,facebook,甚至要组建数据中心来处理.
客户互相之间不通信.
常用应用: 典型的有Web,Telent和电子邮件.

P2P体系结构

对位于数据中心的专用服务器有最小(甚至没有)的依赖.
在主机对之间使用直接通信,这些主机被称为对等方
常用应用:
- 文件共享:BitTorrent
- 对等方协助下载加速器 : 迅雷
- 因特网电话 :Skype
- IPTV : PPStream
未来P2P应用面临三个主要问题
- ISP友好:大多数住宅ISP受制于"非对称的" 带宽应用
- 安全性: 高度分布和开放特性,会对安全带来挑战
- 激励: 未来P2P应用的成功也取决于说服用户自愿向应用提供宽带,存储和计算资源.

2.1.2 进程通信

进行通信的实质是进程(process)

1. 客户和服务进程

在给定的一对进程之间的通信会话场景中,发起通信(即在该会话开始时发起与其他进程联系)的进程被标识为客户,另一方等待连接的是服务器.

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

套接字(socket):进程通过一个称为套接字的软件接口向网络发送电报和从网络接收电报.
- 套接字也称为应用层和运输层的应用程序编程接口(Application Programming Interface ,API) .
应用程序开发者可以控制套接字在应用层端的一切,但是对运输层几乎没有控制,仅限于
- 选择运输层协议
- 设定几个运输层参数(如:最大缓存,最大报文段长度)
在2.7节对套接字进行更为详细的探讨.

3. 进程寻址

目的主机的地址:IP地址(IP address)
- 第四章详细讨论.
目的主机中的接收进程的标识符:端口号(port number)
- 第三章学习端口号.

2.1.3 应用程序所需要的运输服务特性

从四个方面对运输服务分类: 可靠数据传输,吞吐量,定时和安全性

可靠数据运输

就是所谓的丢包
可靠运输传输(reliable data transfer):提供这种服务,确信数据能无差错到达接收进程.
- 电子邮件,文件传输,远程主机访问,Web文档等应用,数据丢失将会造成严重后果.
- 而有些多媒体等应用是容许丢失的应用(loss-tolerant application)

吞吐量

就是所谓的下载速度
带宽敏感的应用(bandwidth-sensitive application)
- 当前许多多媒体应用都是带宽敏感的,尽管尽可能采用自适应编码技术.
弹性应用(elastic application):根据情况利用带宽.
- 电子邮件,文件传输和Web.

定时

有的运输层协议也能提供定时保证.
就是所谓的延迟
- 在游戏和因特网电话中有较高的要求.

安全性

运输层协议提供一种或多种安全服务.

2.1.4 因特网提供的运输服务

1.TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务.
- 面向连接服务: 在应用层数据报文开始流动之前,TCP让客户和服务器互相交换运输层控制信息.
  - 握手阶段: 提示服务器和客户端.
  - 建立一个全双工的TCP 连接(TCP connection)
  - 拆除连接.
- 可靠的数据传送服务:通信进程能够依靠TCP,无差错,按适当顺序交付所有发送的数据.
TCP协议还具有拥塞控制阶段
- 这种服务不一定能为通信进程带来直接好处,给因特网带来整体好处
- 出现网络拥堵时,TCP的拥塞控制机制会抑制发送进程.
安全套接字层(Secure Sockets Layer,SSL:为了提升安全性,提供了一种TCP的加强版本SSL
- 这种强化是在应用层上的,SSL并不是跟TCP/UDP并列的协议

2.UDP服务

UDP是一种不提供不必要服务的轻量级运输协议,它仅提供最小服务.
- 无连接的.
- 不可靠数据传送服务
- 没有拥塞控制

3.运输协议所不能提供的服务

吞吐量和定时方面不能保证,幸好带宽再不断地扩大,也暂时不需要关注.

2.1.5 应用层协议

应用层协议(application-layer protocal): 定义了运行在不同端系统上的应用程序如何相互传递报文.
- 交换的报文类型
  - 请求报文和响应报文
- 各种报文类型的语法
  - 报文的各个字段和这些字段是如何描述的.
- 字段的语义
  - 即这些字段包含的信息的含义
- 一个进程何时发送报文,对报文的响应规则

2.1.6 本书设计的应用协议

HTTP,FTP,STMP,DNS,P2P

2.2 Web 和 HTTP

诞生于 90年代后

2.2.1 HTTP概述

超文本传输协议(HyperText Transfer Protocal,HTTP):Web的应用层协议,Web的核心.

HTTP使用TCP作为它的支撑运输协议.
- HTTP客户向服务器发起一个与服务器的TCP链接,链接建立后,通过套接字接口访问TCP
HTTP是一个无状态协议(stateless protocal)
- HTTP不保存客户的任何信息
- 所以需要cookie,session
对象(object): Web页面由对象组成,一个对象是一个文件
- 一个HTML页面,JPEG图形,CSS文件..........

2.2.2 非持续连接和持续连接

非持续连接(non-persistent connection)
- 每个请求/响应对经过一个单独的TCP连接发送.
持续连接(persistent connection)
- 所有请求/响应对经过相同的TCP连接发送.
- 默认情况使用持续连接.

往返时间(Round-Trip Time,RTT):一个短分组从客户到服务端,再从服务端到客户端说花的时间
- 包括了之前讨论的各种时延.
建立TCP连接传输一个对象需要的时间为 2个RTT+接受文件时间

1. 采用非持续连接的HTTP

每个TCP连接在服务器发送完一个对象后就关闭
- 即每个TCP连接只传输一个请求报文和一个响应报文
相对于持续连接,每次请求对象,需要多花一个RTT的时间.
优点
- 可以并行
缺点:
- 每次建立TCP连接都要占据客户端和服务端的资源.
- 需要多一个RTT的时间来握手.

2. 采用持续连接的HTTP

如果一个连接经过一定时间间隔未被使用,HTTP就会关闭该连接.

2.2.3 HTTP 报文格式

HTTP报文分两种:请求报文和响应报文.

1. HTTP请求报文

给出一个典型的HTTP请求报文

GET /somedir/page.html HTTP/1.1

Host:wwww.someschool.edu

Connection: close

User-agent: Mozilla/5.0

Accept-language: fr

请求行(request line):HTTP请求报文的第一行
- 有3个字段,方法字段,URL字段,HTTP版本字段
  - 方法字段:GET,POST,HEAD,PUT和DELETE
    - 常用GET,POST
首部行(header line): 其后继的行
- Host :指明对象在的主机
- Connection : 指明是否持续连接
- User-agent: 指明客户浏览器
- Accept-language: 期望得到的对象版本.

实体主体 : 当方法字段为POST时使用
详细解说方法字段
- HEAD:类似GET,但只要求返回响应报文,不需要对象
  - 用于调试跟踪.
- PUT: 允许用户上传对象到指定的Web服务器上的指定路径.
- DELETE:允许用户删除

2.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:09 Aug 2011 15:11:04 GMT

Content-Length: 6821

Content-Type:text/html

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

状态行(status line): 协议版本字段,状态码,相应的状态信息
首部行(header line)
- Last-Modified: 请求对象的最后修改时间
  - 对本地缓存非常重要.
- 实体主体(entity body): 报文主要部分,即所请求的对象

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

cookie: 允许站点对用户进行追踪
cookie技术有四个组件:
- HTTP响应报文的一个cookie首部行
- HTTP请求报文的一个cookie首部行
- 用户端系统保留一个cookie文件,由浏览器进行管理.
- 位于Web站点的一个后端数据库
对用户的隐私有侵害.

2.2.5 Web缓存

Web 缓存器(Web cache)也叫代理服务器(proxy server),它是能够代表初始Web服务器满足HTTP请求的网络实体.
- Web缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本
- 通常由ISP购买并安装.
部署Web缓存器有两大原因.
- Web缓存器可以大大减少客户请求的响应时间
- Web缓存器可以大大减少一个机构的接入链路到因特网的通信量
- 缓存命中率在0.2~0.7之间

CDN

内容分发网络(Content Distribution NetWork,CND):地理上分散的缓存器,使大量流量本地化.
- 百度CDN,阿里巴巴CDN.

CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

2.2.6 条件 GET 方法

条件GET(conditional GET)方法: HTTP协议有一种机制,允许缓存器证实它的对象是最新的,这种机制就是条件GET方法.
- 条件GET 包含
  - 请求报文使用GET
  - 请求报文含一个If-Modified-Since: 首部行

请求报文

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com

If-Modified-Since: wed, 7 Sep 2011 09:23:24

如果证实是最新的的响应报文304

HTTP/1.1 304 Not Modified

Date:Sat, 15 Oct 2011 15:39:29

Server: Apache/1.3.0 (Unix)

(empty entity body)

2.3 文件传输协议: FTP

FTP使用并行的TCP连接来传输文件,一个是控制连接(control connection),一个是数据连接(data connection).
- 控制链接用于在两主机之间传输控制信息.
  - 如:用户标识,口令,改变远程目录的命令以及存放(put)和获取(get)文件的命令.
  - 控制链接是持续的
- 数据连接用于实际发送一个文件.
  - 数据连接是非持续的
- 带外传送(out-of-band):因为FTP有个独立的控制链接
  - HTTP就是带内传送.

FTP服务器必须在整个会话期间保留用户的状态(state).
- 大大限制了FTP同时维持的会话总数.
- 所以也是HTTP的优势.

2.3.1 FTP 命令与回答

每个命令由4个大写字母组成,有些还有可选参数

USER username :传递用户标识

PASS password :用于向服务器发送用户口令

LIST: 用户请求服务器回送当前远程目录中的所有文件列表.该文件列表是经一个数据传送

RETR filename: get 文件

STOR filename: put 文件

回答总是3位数字,后面跟一个可选信息

331 Username OK,Password required

125 Data connection already open;transfer starting

425 Can't open data connection

452 Error writing file

详细学习请阅读RFC 959

2.4 因特网的电子邮件

用户代理(user agent)
- 用户代理允许用户阅读,回复,转发,保存和攒写报文.
- 微软的Outlook,Apple Mail,QQ mail
邮件服务器(mail server)
- 外出报文队列: 等待发送.
- 报文队列: 无法发送出去的在这里每30分钟发一次.
- 邮箱(mailbox): 管理和维护发送给邮箱主人的报文.
简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)
- SMTP 是因特网电子邮件中主要的应用层协议.
- 使用TCP协议.
- 也分为SMTP客户端和SMTP服务端.

2.4.1 SMTP

报文的体部分只能使用 7 比特ASCII
- 即多媒体的2进制文件编码为ASCII再传递,之后再解码.
- HTTP并不需要
SMTP一般不使用中间邮件服务器发送邮件,即使这两个邮件服务器位于地球的两端也是这样.

报文以CRLF.CRLF结束
- CR:回车
- LF:换行
是可持续的连接,发送完一个报文,可以继续发送第二个.
- 以 QUIT作为断开连接的命令.

2.4.2 与 HTTP 对比

关于推拉

SMTP是一种推格式,所以在取报文时,不用SMTP协议.
HTTP 主要是拉格式

对于报文的格式

SMTP 强制要求7比特ASCII码
HTTP 不要求

既包含文本又包含图片的文档

HTTP : 一个对象一个响应报文.
SMTP : 全部赛一起.

2.4.3 邮件报文格式和 MIME

邮件报文格式区别于SMTP协议格式,注意注意

From: alice@crepes.fr

To: bob@hamburger.edu

Subject: Searching for the meaning of life

This is main text.

首部行:
- 必须包含 From,To 首部行
- 可能包含Subject等首部行.
报文体: 用一个空行相隔
RFC 5322定义.

2.4.4 邮件访问协议

邮件访问协议诞生的原因

用户代理不能使用SMTP 取回报文.
- 因为SMTP只能进行拉操作.
所以产生了一些流行的邮件访问协议
- 第三版的邮局协议(Post Office Protocol--Version 3,POP3)
- 因特网邮件访问协议(Internet Mail Access Protocol,IMAP)
- HTTP

1.POP3

POP3是一个极为简单的邮件访问协议.
- 因为协议非常简单,所以功能也有限
当用户代理打开了一个到邮件服务器端口 110的TCP连接后,开始工作.
- 特许(authorization)阶段:用户代理(以明文形式)发送用户名和口令鉴别用户
  - user <user name>
  - pass <password>
- 事务处理阶段:
  - 用户代理取回报文
    - list: 展开列表
    - retr <mailname>: 打开指定邮件
  - 对报文做删除标记.
    - dele <mailname>:
  - 取消报文删除标记.
  - 获取邮件的统计信息.
  - quit:进入更新阶段
- 更新阶段:邮件服务器删除那些被标记为删除的报文.
服务器的回答只有两种: +OK,-ERR
POP3 没有给用户提供任何创建远程文件夹并未报文指派文件夹的方法.

2.IMAP

如上所说,POP3 没有给用户提供任何创建远程文件夹并未报文指派文件夹的方法.所以IMAP应运而生.

IMAP也是一个邮件访问协议,比POP3更加复杂和功能齐全.
- 第一个是文件夹功能.
- 第二个是允许用户取出报文组件的功能.
  - 有时可能只想取出一个报文头.

3. 基于Web的电子邮件

用户代理就是普通的浏览器.
接收的时候使用的是HTTP而不是其余POP3,IMAP.
发送的时候也是HTTP,而不是SMTP.
服务器传送的时候依旧是SMTP

2.5 DNS: 因特网的目录服务

2.5.1 DNS提供的服务

域名系统(Domain Name System): 主机名到IP地址转换的目录服务.
- 一个由分层的DNS服务器实现的分布式数据库.
- 一个使得主机能够查询分布式数据库的应用层协议.
DNS使用的运输层协议是UDP,使用 53 号端口

其余服务

主机别名(host aliasing)
邮件服务器别名(mail server aliasing)
负载分配(load distribution)
- 应用情形: 一个域名分配了多个IP,循环的使同一个域名下每个主机负载均衡.

2.5.2 DNS 工作机概述

DNS 工作过程

很多基于UNIX的系统可以使用gethostbyname()这样的API调用DNS.
主机上的DNS向网络发送一个DNS查询报文.
- 所有DNS报文接受和发送都是通过UDP经端口53发送.
用户收到DNS回答报文,包含了所需要的IP.

DNS 实现- 分布式数据库

DNS是因特网上实现分布式数据库的精彩典范

1.分布式层次数据库

假定一个客户需要知道www.amazon.com的IP地址

首先与根服务器联系,返回*域名com的TLD服务器的IP地址.

然后与TLD服务器之一练习,将返回amazon.com的权威服务器地址.

最后,与权威服务器地址联系,返回www.amazon.con 的IP地址.

根 DNS 服务器: 在因特网上当前有且只能有13个根DNS服务器 (标号为A-M)
- 要让所有的根服务器数据能包含在一个512字节的UDP包中
  - 根服务器只能限制在13个
  - 而且每个服务器要使用字母表中的单个字母命名
*域服务器(TLD): 这些服务器负责*域名如com,org,net,edu和gov,以及所有国家的*域名如uk,fr,ca和jp.
权威 DNS 服务器:
- 一个组织机构自己搭建的权威DNS服务器
- 租借服务提供商的一个权威DNS服务器
本地DNS服务器: 不属于DNS的层次结构.
- 起着代理的作用.

递归查询: 请求主机到本地DNS服务器是递归查询
迭代查询: 本地DNS服务器与其余服务器的回话是迭代查询

2.DNS缓存

一般保存两天.

2.5.3 DNS记录和报文

资源记录(Resource Record,RR):RR提供了主机名到IP地址的映射.
- 四元组:(Name,Value,Type,TTL)
  - TTL: 资源记录应当在缓存中删除的时间.
  - NAME和VALUE的值取决于Type
- Type
  - Type = A
    - Name是主机名
    - Value是对应的IP地址.
    - 比如:(relay1.bar.foo.com,145.37.93.126,A)
  - Type = NS
    - 则 Name是个域如:(foo.com)
    - Value是获得该域中主机IP地址的权威DNS服务器主机名.
    - 比如:(foo.com,dns.foo.com,NS)
  - Type = CNAME
    - Value是别名为Name的规范主机名.
    - 比如:(foo.com,relay1.bar.foo.com,CNAME)
  - Type = MX
    - Value是别名为Name的邮件服务器的规范主机名.
    - 比如:(foo.com,mail.bar.foo.com,MX)
DNS回答报文: 一般包含了一条或多条资源记录.

1.DNS报文

查询和回答报文都是下面的格式

首部区域:前12个字节,各有2字节
- 标识符: 用于标识该查询
  - 这个标识符会被复制到对查询的回答报文.
  - 用于匹配发送的请求和接受到的回答.
- 标志 : 有若干标志位.
  - - QR:1 比特的 查询/回答 指出是查询报文(0)还是回答报文(1).
- 还有首部后的四类数据区域的数量.
问题区域: 包含正在查询的信息
- 名字字段
- 类型字段
回答区域: 包含了最初请求的名字的资源记录
- 可以包含多条RR,所以一个主机名可以对应多个IP.
权威区域: 包含了其他权威服务器的记录.
附加区域: 包含了其他有帮助的记录.
- 对于MX请求,回答区域是一个类型MX的RR,附加区域是个A的RR

总结

可以使用nslookup直接向某些DNS服务器发送一个DNS查询报文.

在DNS数据库插入记录

有以下记录需要插入

你的DNS服务器的名字和IP地址

(network.com,dns.network.com,NS)

(dns,network.com,212,212,212,1,A)

你的WEB服务器的IP地址
```
(www.network.com,212,212,71.4,A)
```
用于邮件的MX类型.

2.6 P2P应用

讨论两种P2P应用

文件分发: BitTorrent 协议
分布式散列表 : 大型对等数据库.

2.6.1 P2P 文件分发

1.P2P 体系结构的扩展性

C-S模式下载一个文件所需要的时间
- N: 下载人数
- F: 文件大小
- Us: 服务器上传速度
- dmin: 最小下载速度
P2P模式下下载一个文件所需要的时间

2. BitTorrent

BitTorrent: 用于文件分发的流行 P2P 协议.
洪流(torrent):参与一个特定文件分发的所有对等方的集合被称为一个洪流
文件块(chunk): 一个洪流中的对等方彼此下载等长度的文件块(chunk)
- 典型的块长度为256KB
实际运行大概:
- 一个对等方加入洪流,不断地下载块,也为其他对等方上载了很多块.
- 可以在任何时候离开洪流,也能下载完后继续(大公无私)的上传.

我们更为仔细的观察BitTorrent运行的过程

追踪器(tracker): 每个洪流具有一个的基础设施结点,跟踪洪流对等方.
- 当一个对等方加入洪流时,它向追踪器注册自己
- 并周期性通知洪流自己还在洪流中.

#### 一步一步详细介绍
![image_1b2atb86r130obbl1b6gt2e1grs1g.png-182.4kB][23]

Alice加入洪流,追踪器随机选择一个对等方子集的IP发给Alice.
Alice 试图与列表所有对等方创建并行的TCP连接.
- 领近对等方: 成功建立连接的对等方(此图只有三个)
- 邻近对等方随时间而变化.
Alice 周期性的询问每个邻近对等方他们具有的块列表.
Alice 对他还没有的块发出请求(TCP连接).
因此在任何时刻,Alice拥有块,并知道邻居有哪些块,有两个任务要做.
- 请求哪些块?
  - 稀缺优先技术: 针对邻居最稀缺的块进行请求.
- 给哪些邻居发送块?
  - 对换算法:
    - 基本想法: 根据当前能够以最高速率向她提供数据的邻居提供最高优先权.
    - 疏通:根据下载速度确定k个邻居,还有一个待试探称为疏通.
      - 每 10s 会重新计算下载速度.
      - 每 30s 会随机给邻居B发送块,使得自己可能成为B的疏通.
    - 阻塞:其余除疏通外的对等方.
还有片,流水线,随机优先选择,残局模型,反怠慢等有趣的机制.
这样一报还一报的机制提高用户的积极性..

2.6.2 分布式散列表

分布式散列表(Distributed Hash Table,DHT)
- 每个对等方拥有总体的一个小子集.
- 允许任何对等方用一个特别的key来查询该分布式数据库.
- 分布式数据库定位拥有该key-value的对等方,向查询返回key-value.
- 任何对等方也能插入key-value.
散列的由来
- 每个对等方式取 [0,2^n-1]散列表上的id.
- 最近原则: 对每个key哈希一下得到一个id,并 mod 2^n,存入跟这个id最接近的散列表中.
- 然后利用二分查找的思想.

环形DHT

其实就是一种二分查找的思想而已.
每个节点拥有Logn个捷径.

对等方干扰

即插入,删除一个对等方所做的操作.
以后需要的话,再仔细读相关论文.

2.7 TCP套接字编程

通过一个简单的UDP程序和一个简单的TCP程序来介绍 UDP和TCP套接字编程.

我们用Python呈现这些程序.

2.7.1 UDP套接字编程.

UDPClient

from socket import *

serverName = 'localhost'

serverPort = 12000

clientSocket = socket(AF_INET,SOCK_DGRAM)

message = bytes(input('Input lowercase sentence:'),encoding="UTF-8")

clientSocket.sendto(message,(serverName,serverPort))

modifiedMessage,serverAddress = clientSocket.recvfrom(2048)

modifiedMessage = modifiedMessage.decode()

print(serverAddress)

print (modifiedMessage)

clientSocket.close();

socket.AF_INET:指示了底层网络使用 IPv4
socket.DGRAM : 意味着是一个UDP套接字
recvfrom : 代表缓存长度

UDPServer

from socket import *

serverPort = 12000

serverSocket = socket(AF_INET,SOCK_DGRAM)

serverSocket.bind(('',serverPort))

print("The server si ready to receive")

while True:

	message,clientAddress = serverSocket.recvfrom(2048)

	modifiedMessage = message.upper()

	serverSocket.sendto(modifiedMessage,clientAddress)

2.7.2 TCP套接字编程

欢迎套接字
连接套接字

TCPClient.py

from socket import *

serverName = 'localhost'

serverPort = 12000

clientSocket  = socket(AF_INET,SOCK_STREAM)

clientSocket.connect((serverName,serverPort))

sentence = bytes(input('Input lowercase sentence'),encoding='UTF-8')

clientSocket.sendto(sentence)

modifiedSentence = clientSocket.recv(2048)

modifiedSentence.decode()

print('From Server:'+modifiedSentence)

clientSocket.close();

TCPServer
```
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 1:

connectionSocket,addr = serverSocket.accept()

sentence = connectionSocket.recv(1024)

capitalizedSentence = sentence.upper()

connectionSocket.send(capitalizedSentence)

connectionSocket.close()

```

码农公寓

[A Top-Down Approach][第二章 应用层]

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

客户-服务端体系结构

P2P体系结构

2.1.2 进程通信

1. 客户和服务进程

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

3. 进程寻址

2.1.3 应用程序所需要的运输服务特性

可靠数据运输

吞吐量

定时

安全性

2.1.4 因特网提供的运输服务

1.TCP服务

2.UDP服务

3.运输协议所不能提供的服务

2.1.5 应用层协议

2.1.6 本书设计的应用协议

2.2 Web 和 HTTP

2.2.1 HTTP概述

2.2.2 非持续连接和持续连接

1. 采用非持续连接的HTTP

2. 采用持续连接的HTTP

2.2.3 HTTP 报文格式

1. HTTP请求报文

2.HTTP响应报文

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

2.2.5 Web缓存

CDN

2.2.6 条件 GET 方法

2.3 文件传输协议: FTP

2.3.1 FTP 命令与回答

2.4 因特网的电子邮件

2.4.1 SMTP

2.4.2 与 HTTP 对比

2.4.3 邮件报文格式 和 MIME

2.4.4 邮件访问协议

邮件访问协议诞生的原因

1.POP3

2.IMAP

3. 基于Web的电子邮件

2.5 DNS: 因特网的目录服务

2.5.1 DNS提供的服务

2.5.2 DNS 工作机概述

DNS 工作过程

DNS 实现- 分布式数据库

1.分布式层次数据库

2.DNS缓存

2.5.3 DNS记录和报文

1.DNS报文

总结

在DNS数据库插入记录

2.6 P2P应用

2.6.1 P2P 文件分发

1.P2P 体系结构的扩展性

2. BitTorrent

2.6.2 分布式散列表

环形DHT

对等方干扰

2.7 TCP套接字编程

2.7.1 UDP套接字编程.

2.7.2 TCP套接字编程

相关文章

[A Top-Down Approach][第二章应用层]

2.4.3 邮件报文格式和 MIME