【计算机网络 - 自顶向下方法】应用层（SMTP、POP3、DNS、P2P）

1. Electronic Mail

电子邮件应用画像

• 应用层传输对象：邮件
• 网络应用架构：客户 - 服务器架构
• 使用传输服务：TCP
• 应用层协议：
  • 邮件传输协议：SMTP（端口号25）
  • 邮件访问协议：POP3（端口号110），IMAP（端口号143），HTTP（端口号80）
• SMTP、POP3、IMAP采用命令/响应交互

1.1 电子邮件系统

最初由三个部分组成：

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

用户代理

• 编辑、阅读、回复邮件等。
• 将要外发的邮件发送到用户的邮件服务器。
• 从用户邮箱中取邮件。
• 一些用户代理：Outlook, elm, Mozilla, Thunderbird

邮件服务器

• 用户信箱：存放到来的邮件。
• 发送报文队列：存放要发送出去的邮件。
• 报文传输代理MTA：运行在服务器后台的系统守护进程，负责在邮件服务器之间传输邮件，即将收到的邮件放入用户信箱。

电子信箱

• 电子信箱：
  • 由计算机上的一个存储区域（如磁盘上的一个文件）组成。
  • 每个信箱均被分配了唯一的电子邮件地址。
• 电子邮件地址：
  • 由两个部分组成，形如：mailbox@computer。
  • 前者为标识用户信箱的字符串，后者为信箱所在的邮件服务器的名字。

简单邮件传输协议–SMTP [RFC 2821]

• 邮件服务器之间传输邮件采用客户-服务器模式：
  • 客户：发送邮件的邮件服务器（报文传输代理）
  • 服务器： 接收邮件的邮件服务器（报文传输代理）
• SMTP使用TCP协议，服务器端口为25
• 发送方和接收方的邮件服务器之间直接传输邮件
• SMTP采用命令/响应交互方式：
  • 命令: ASCII文本
  • 响应: 状态码和短语
• 报文只能包含简单ASCII文本，即7位ASCII码（最初仅为英文电子邮件而设计）

邮件发送示例Scenario: Alice sends message to Bob

1. Alice使用用户代理编辑邮件，发送给bob@someschool.edu
2. Alice的用户代理将报文发送给其邮件服务器（使用SMTP）。
3. 邮件被置于邮件服务器的发送报文队列中。
4. Alice的邮件服务器与Bob的邮件服务器建立TCP连接，然后发送 Alice的邮件。
5. Bob的邮件服务器将邮件放置在Bob的信箱中。
6. Bob调用他的用户代理阅读邮件。
   

Q：为什么不是直接从 User Agent 直接发送到 User Agent 呢？
A：User Agent这样的终端程序并不是实时在线的，若Bob的Mail Server暂时出现了问题，Alice的 Mail Server会在一段时间内不断尝试发送，尝试多次后才宣布发布失败。User Agent 并不是一直在线的无法向 Mail Server 一样重复这样的过程。

邮件传送具体实现

  假设Alice的邮件已经从代理服务器传输到了邮件服务器上，Alice的邮件服务器试图将邮件传送到Bob的邮件服务器上。

1. 实现连接与握手
   • MTA客户与MTA服务器在端口25建立TCP连接。
   • 服务器发送服务就绪报文。
   • 客户发送HELO报文，用域名标识自己。
   • 服务器响应。
     
   • 若正常则回复 250 OK，不正常回复 421 Service not Available
2. 发送邮件内容
   

可能出现的错误：
451：处理出错
452：存储空间不足

3. 结束传输

• 客户发送QUIT命令
• 服务器响应
• 释放TCP连接
  

几个要点：

• SMTP使用持久连接：
  • 可以在一条TCP连接上传输多个报文（FTP只传输一个文件，HTTP可传输一个或多个对象）
  • 一个方向的报文传输结束后，可以在另一个方向上传输报文（SMTP特有的）
• SMTP 服务器使用 “.” 表示报文结束（FTP使用关闭连接表示文件结束，HTTP使用长度域表示报文结束）。
• SMTP要求报文（报头和实体）只包含简单ASCII文本（HTTP无此要求）。

1.2 邮件报文格式

如何传输包含非ASCII文本的报文?

• 现在的电子邮件要求能传输其它语系的文字，甚至非文本信息（如图片）。
  • 非ASCII文本形式的数据，在发送前须转换成简单ASCII文本。
• 非ASCII文本的报文大多具有特殊的数据类型，需要特殊的邮件浏览器（如JPEG图形的解压缩软件）来阅读。
  • 需扩展报文的数据类型。

Base64编码

Base64用来将一个二进制字节序列，转换成由ASCII字符序列构成的文本。

每24比特数据划分成4个6比特的单元，每个单元编码成一个ASCII字符，其对应关系为：

• 0～25编码成’A’～’Z’
• 26～51编码成‘a’～‘z’
• 52～61编码成‘0’～‘9’
• 62和63分别编码成‘＋’和‘／’
• 若最后一组只有8比特或16比特，分别加上‘＝＝’和 ‘＝’ 后缀
• 回车和换行忽略，可以插在任何地方
  

quoted-printable编码

适用于绝大部分都是ASCII字符的报文实体，其编码方法是：

• 每个ASCII字符保持不变
• 对于非ASCII字符（大于127的字符），将该字符的十六进制表示用两个ASCII字符标记，前面冠以特殊字符"="。
  

多用途因特网邮件扩展协议MIME

  扩展了RFC 822，允许实体具有不同的数据类型，并规定了非ASCII文本信息在传输时的统一编码形式。

扩充了一些首部行，最重要的是：

• Content-Transfer-Encoding：实体采用的传输编码形式。
• Content-Type：实体的数据类型及子类型。
  

1.3 邮件访问

邮件访问方式：

• 早期：用户登陆到邮件服务器上，直接在服务器上运行一个邮件阅读程序来阅读邮件。
• 今天：用户在终端上安装用户代理，获取和阅读邮件。

Q：能将用户信箱放在本地终端吗？
A：不能，用户终端不可能一直连在因特网上

Q：用户代理能用SMTP从邮件服务器获取邮件吗？
A：不能，SMTP是一个“推”协议，只能将邮件从用户代理推送到其邮件服务器，或从发送方邮件服务器推送到 收件人邮件服务器。

解决从邮件服务器获取邮件的方案：设计一个新的协议从服务器获取邮件。

邮件的两阶段交付

• 在具有永久因特网连接的计算机上运行一个SMTP服务器，为用户分配一个永久信箱。
• 第一阶段：邮件被投递到收信人的永久信箱（邮件传输阶段）。
• 第二阶段：用户从永久信箱中获取邮件（邮件访问阶段）。
• 为此，带永久信箱的计算机必须运行两个服务器程序：
  • SMTP服务器：收发用户邮件，将收到的邮件放入用户信箱。
  • 邮件访问服务器：允许用户从信箱中提取邮件。

邮件访问协议
可以从服务器获取邮件的协议有：

• POP（只有一些最基础的功能）: Post Office Protocol [RFC 1939]
  • authorization (agent <—>server) and download
• IMAP（支持更复杂的操作）: Internet Mail Access Protocol [RFC 1730]
  • more features (more complex)
  • manipulation of stored msgs on server
• HTTP: gmail, Hotmail, Yahoo! Mail, etc.

POP3协议的两个阶段

1. 认证和授权阶段

• 客户命令:
  • user: declare username
  • pass: password
• 服务器响应
  • +OK
  • -ERR

S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on

2. 事务阶段

• 客户命令:
• list: list message numbers
• retr: retrieve message by number
• dele: delete
• quit

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 2 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off

  在以上例子中使用了"download and delete" 模式，在另一台终端上无法再获取邮件，而"Download-and-keep"模式可将邮件保留在服务器中。

IMAP所具有的更多的功能：

• 所有邮件保存在服务器上。
• 允许用户将邮件组织在文件夹中。
• 允许用户在文件夹之间移动邮件。

基于web的邮件访问：HTTP

• 用户代理为普通浏览器：
  • 发送邮件：浏览器使用 HTTP协议 将邮件发送到邮件服务器。
  • 获取邮件：浏览器使用 HTTP协议 从信箱取邮件。
  • 传输邮件：邮件服务器之间仍使用 SMTP协议 传输报文。
• 和IMAP一样，用户可以在远程服务器上用文件夹来组织他们的邮件。
• 下图展示了邮件传输的两种方式：
  
  • 红色线代表为像Outlook这样的代理服务器的邮件传输方式。
  • 蓝色线代表为基于web代理服务器的邮件传输方式。

现代因特网电子邮件系统的组成

• 用户代理
• 邮件服务器
• 简单邮件传输协议SMTP
• 邮件访问协议（POP3，IMAP，HTTP）

小结

• 电子邮件系统：
  • 4个组成部分。
• SMTP协议：
  • 使用TCP协议，服务器端口号25。
  • "推"协议：将邮件推向用户信箱（POP3默认端口号是110）。
  • 命令/响应交互方式。
  • 信体只能包含简单ASCII文本。
• MIME协议：
  • 允许信体包含非ASCII文本。
  • 规定传输编码类型，扩展数据类型。
• 两阶段交付过程：
  • 邮件投递：邮件从发信方投递到用户信箱。
  • 邮件访问：收信人从用户信箱获（拉）取邮件。

理解HTTP、FTP、SMTP设计上的不同

• HTTP、FTP、SMTP均是在TCP连接上传输文件，但是在设计上有一些不同
• 使用持久连接或非持久连接：HTTP可在一条TCP连接上传输多个对象，SMTP可以传输多个邮件，FTP只传输一个文件。
• 文件传输结束的标记：HTTP使用长度指示报文结束，FTP使用关闭连接表示文件结束，SMTP 使用 “.” 表示报文结束。
• 文件内容的要求：SMTP要求邮件只包含简单ASCII文本（可通过MIME优化），FTP和HTTP无此要求。
• 客户-服务器交互方式：HTTP采用报文交互，SMTP和FTP采用命令/响应交互。

2. DNS（Domain Name System）

因特网的目录服务DNS：将主机名映射到IP地址。（google.com—> 8.7.198.46）

DNS实现为一个应用层服务：

• 由其它网络应用使用的服务
• 客户 - 服务器模式
• 传输服务：主要使用UDP，有时使用TCP。
• 端口号53
• 请求/响应报文交互

2.1 DNS提供的服务

• 主机名 - IP地址转换
• 主机别名：
  • 允许主机除了规范名外，具有一个或多个别名（易于记忆），如www.ustc.edu.cn
  • 提供主机别名到规范名的映射。
  • 迁移服务不需要修改主机名。
• 邮件服务器别名：
  • 允许使用域名作为邮件服务器的别名，如：xxx@ustc.edu.cn
• 负载分配：
  • 允许一个规范主机名对应一组IP地址。
  • 将服务请求在一群相同功能的服务器之间分配。

2.2 DNS工作机理

将主机名转换成IP地址：

1. 应用程序（如浏览器）调用一个本地例程（解析器），主机名作为参数之一传递。
2. 解析器向网络中的DNS服务器发送查询报文，包含要查询的主机名。
3. 解析器收到包含IP地址的响应报文。
4. 解析器将IP地址返回给调用者（如浏览器）。

对应用程序而言，DNS是一个提供直接转换服务的黑盒子。

DNS是一个分布式数据库

Q: 为什么不使用集中式的DNS？

• 单点失效
• 流量集中：单个DNS服务器需处理全部查询
• 响应时间长：远距离的集中式数据库
• 需要维护庞大的数据库

分布式环境中的名字空间

如何在分布式环境下避免出现名字冲突？

DNS使用名字空间来规范对主机的命名：

• 名字空间是因特网主机名字的集合，它同时给出了命名主机的方法。
• 概念上，因特网被划分成200多个顶级域，每个顶级域可继续划分子域，依次类推。
• 主机名字采用分层的命名方法。

域名

域（domain）：名字树中，以任何一个节点为根的子树构成一个域。
标记（label）：树上每一个节点都有一个标记（最多63个字符），树根的标记是一个空字符串。
域名（domain name）：某个域的名字表示为：从该域开始向上直到树根的标记序列，标记之间用句点隔开（类似国外邮政地址的写法）。

域名的任一后缀也是一个域，同一个机构内的主机具有相同的域名后缀。
每个节点只需保证其孩子节点的标记不重名。

顶级域

  顶级域分为组织域、国家域和反向域三种。

• 组织域
    由美国国内及一些国际组织使用。
  
• 国家域
    使用二字符的国家代码，每个国家对应一个。
  
• 反向域

顶级域名为arpa，用来将一个IP地址映射为注册的域名，反向域名解析是为了溯源。

DNS提供了一个反向解析域in-addr.arpa：

• 欲解析的IP地址表示成像域名一样的一个串，例如，IP地址132.34.45.121表示为 121.45.34.132.in-addr.arpa。
• 以这个字符串作为参数调用解析器

电信运营商使用自己的DNS服务器提供相关IP地址的反向解析服务。

域名服务器的组织层次

客户想知道www.amazon.com的IP地址：

• DNS客户查询根服务器，得到com域的DNS服务器地址。
• DNS客户查询com域的DNS服务器，得到amazon.com域的DNS服务器地址。
• DNS客户查询amazon.com域的DNS服务器，得到www.amazon.com的IP地址。

顶级域服务器，权威服务器

• 顶级域 (Top Level Domain, TLD) 服务器:
  • 每个TLD服务器负责一个顶级域。
  • 知道其所有二级子域的域名服务器的地址。
• 权威DNS服务器:
  • 机构的DNS服务器，提供机构内部服务器的名字映射。
  • 提供一个主域名服务器、一个或多个辅助域名服务器。
  • 可由机构维护，也可委托ISP维护。

本地DNS服务器

• 严格来说，本地DNS服务器不属于DNS服务器的层次结构。
• 每个ISP都有一台本地DNS服务器，也称“默认的DNS服务器”。
• 解析器的DNS查询报文实际上发送给本地DNS服务器。
• 本地DNS服务器起着代理的作用，负责将DNS查询报文发送到DNS层次结构中，并将查找结果返回给解析器。

域名解析的例子

Q：cis.poly.edu上的一台主机想知道gaia.cs.umass.edu的IP地址。

物理服务器的层次

  一个物理服务器保存的信息可能涉及域名空间的若干层，它也可以把它的域划分成若干子域，把其中的一些子域委托给其它服务器。

  实际的物理服务器的层次与域名空间的逻辑层次不同。

DNS缓存

• 每当收到一个响应报文，DNS服务器将报文中的映射信息缓存在本地（每一层的DNS都有缓存）。
• DNS服务器首先使用缓存中的信息响应查询请求。
• DNS缓存中的映射在一定时间后被丢弃
• 特别地，本地DNS服务器通常会缓存TLD服务器的IP地址，因而很少去访问根服务器

2.3 DNS资源记录

DNS更准确的说法： 存储资源记录（RR）的分布式数据库。

• Type=A（Address）
  • Name：主机名
  • Value：IP地址
• Type=NS（Name Server）
  • Name：域 (e.g. foo.com)
  • value：该域的权威DNS服务器的主机名
• Type=CNAME（Canonical Name）
  • Name：别名
  • Value：规范名
• Type=MX（Mail Exchanger）
  • Name：域(e.g. foo.com)
  • Value：该域的邮件服务器名字

DNS数据库内容示例

2.4 DNS协议，报文

DNS协议: 定义了查询和响应两种报文，查询和响应使用相同的报文格式。


DNS报文的封装

• DNS主要使用UDP，有时使用TCP，服务器的熟知端口都是53：
  • 当响应报文的长度小于512字节时，使用UDP
  • 当响应报文的长度超过512字节时，使用TCP
  • 当解析器事先不知道响应报文的长度时，先使用UDP；若响应报文的长度超过512字节，服务器截断这个报文，置DNS报文首部的TC标志为1；解析程序打开TCP连接，并重复这个请求，以便得到完整的响应。
• 为什么DNS响应报文的长度小于512字节时，使用UDP，响应报文的长度超过512字节时，使用TCP？
  • 这是因为UDP没有数据分段的能力，一旦发送的报文长度过长，就需要切割成几个报文段来传送。这就有可能导致信息被分成多个报文段发送丢失，造成严重的数据损失。而TCP传输数据时，可以对数据进行分段和重组，保证数据的完整性，因此更适合传输大型的DNS响应报文。另外，DNS使用TCP的情况也不仅限于响应报文超过512字节，还包括查询应答中的TCP标识位被置位、端口53被占用等情况。

往DNS中插入资源记录

• example: new startup “Network Utopia”。
• 向DNS注册机构注册域名“networkutopia.com”
  • 提供权威DNS服务器（主域名服务器，辅助域名服务器）的名字和IP地址。
  • 对每个权威域名服务器，注册机构往 com TLD 服务器中插。
    入两条资源记录，例如：(networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)
• 建立权威DNS服务器，特别是：
  • 建立www.networkuptopia.com的Type A记录。
  • 建立networkutopia.com的Type MX记录，以及相应邮件服务器的A记录。

2.5 小结

• DNS
  • 提供了一种按层次结构命名主机的方法
  • 实现了一个由DNS服务器构成的分布式数据库
  • 提供了查询域名数据库的应用层协议
• 域名服务器的类型和层次（逻辑层次，物理层次）
• DNS服务的调用方法：
  • 向本地DNS代理的一个RPC调用
  • 递归+迭代的查询方式
• DNS协议：
  • 主要使用UDP，也可以使用TCP，端口号均为53
  • 报文请求/响应交互
• DNS缓存

3. P2P Applications

一个典型的例子：（点对点）

• Alice在她的笔记本电脑上运行P2P客户应用。
• 通过ISP连接到因特网上。
• 请求歌曲 “Hey Jude”。
• P2P客户应用显示拥有该歌曲拷贝的对等方列表。
• Alice选择其中的一个对等方，比如Bob。
• 文件从Bob的PC机下载到Alice的笔记本电脑。
• 当Alice从Bob的PC机下载时，其他用户可能从Alice的笔记本电脑下载。
• Alice的P2P应用程序既是一个Web客户，又是一个临时的Web服务器。

1. 类型一：文件共享服务Napster的设计（最早期）

• 每个对等方与一个集中式的目录服务器连接，告知：
  • 自己的IP地址。
  • 可以共享的内容。
• Alice查询歌曲 “Hey Jude”。
• Alice从Bob下载音乐文件。

集中式目录的问题：

• 单点失效。
• 目录服务器成为性能瓶颈。
• 由于版权问题，易成为诉讼的对象。

2. 类型二：查询洪泛—Gnutella

• 完全分布：没有集中式服务器。
• 存在公共域协议。
• 有许多Gnutella客户软件。
• 如果对等方X与Y之间存在一条TCP连接，称它们之间存在一条边（虚拟链路）。
• 所有活跃的对等方以及它们之间的边，形成一个覆盖网络（overlay net）。
• 一个对等方通常有 < 10 个的覆盖网邻居。

Gnutella: 对等方加入：

• 新加入的对等方Alice必须在Gnutella网上发现其它对等方: 使用一个候选对等方列表（客户软件中自带）。
• Alice依次和候选列表中的对等方尝试建立TCP连接。
• 洪泛: Alice向每个覆盖网邻居发送Ping报文；每个邻居向他的覆盖网邻居转发Ping报文……
• 收到Ping报文的对等方向Alice发送Pong报文。
• Alice收到许多Pong报文，从而可以建立更多的TCP连接。

Gnutella: protocol：

• 查询方在已有的TCP连接上发送Query message。
• 收到消息的对等方向其邻居转发查询报文。
• 有内容的对等方返回QueryHit。

3. 类型三：层次结构的覆盖网

• 介于集中式目录和查询洪泛之间。
• 每个对等方或是一个超级节点（group leader），或是从属于某个超级节点的普通节点：
  • 每个普通节点与其超级节点之间建立TCP连接。
  • 某些超级节点之间建立TCP 连接。
• 超级节点知道其所有从属节点的共享内容列表。

4. 客户 - 服务器和P2P架构文件分发时间的比较

Question：将文件从一台服务器分发到网络中的N个终端，需要多少时间？

4.1 客户-服务器架构的文件分发时间

4.2 P2P架构的文件分发时间

4.3 分发时间比较

4.4 P2P案例学习: BitTorrent

BitTorrent概述

• 文件被划分成长为256KB的块。
• 对等方加入洪流时没有数据块，但随着时间的推移逐步积累。
• 对等方在下载数据块的同时，也向其它对等方上载数据块。
• 对等方可以动态加入或离开系统。
• 一旦对等方获取了整个文件，它可以（自私地）离开，也可以（无私地）留在网络中，为其它对等方上传文件块。

BitTorrent操作

4. Video Streaming（视频流）

视频的概念

• 视频是以恒定速率播放的图像序列：比如，24帧/秒
• 数字图像是一个像素阵列：每个像素用一些比特来表示。
• 图像编码技术利用图像的帧内冗余和帧间冗余来减少需要使用的比特数：（例如存储帧之间的差）
  • 空间冗余：帧内
  • 时间冗余：帧间

视频编码速率

• CBR: (constant bit rate)：编码速率固定。
• VBR: (variable bit rate)：编码速率可变。
• 视频编码标准:
  • MPEG 1 (CD-ROM) 1.5 Mbps
  • MPEG2 (DVD) 3-6 Mbps
  • MPEG4 (often used in Internet, < 1 Mbps)

流式存储视频的实现

• 视频作为一个普通文件，保存在HTTP服务器中。
• 服务器与客户建立TCP连接，发送文件。
• 视频应用周期性地从应用缓存中取帧、解码、展示。

为满足不同用户不同的编码效率所以使用：流式多媒体—DASH。

流式多媒体: DASH

• DASH： Dynamic, Adaptive Streaming over HTTP
• 服务器：
  • 将视频文件划分成多个块。
  • 每个块以不同的码率编码和存储。
  • 元文件为不同的块提供URL。
• 客户：
  • 周期性地测量到服务器的网络带宽。
  • 查询元文件，每次请求一个块。
    • 选择当前带宽可支持的最大码率。
    • 不同时刻可以选择不同码率的块。
• 客户端能够"智能地"确定：
  • 什么时候请求块（避免缓存不足或溢出）
  • 请求什么码率的块（获得当前最好的视频质量）
  • 向谁请求块（离客户最近或具有最高带宽的URL）

将内容流式传输给同时在线的大量用户的方法

• 方法1: 使用一个巨型服务器（不可行）
  • 单点故障。
  • 网络拥塞点。
  • 远端用户传输距离长，跨多个ISP，带宽低。
  • 同一条链路上传输多个视频拷贝 ，浪费带宽。
• 方法2: 在地理上分布的多个站点存储和提供服务 (CDN)：
  • enter deep: 将CDN服务器深入部署到大量接入网中，靠近用户。
    • Akamai拥有1700个站点。
  • bring home: 将少量（几十个）较大的集群部署在靠近接入网的POP中。
    • Limelight采用此法。

5. 内容分发网络（CDN）

• 在多个CDN站点存储内容的拷贝。
• 当用户从CDN请求内容时：
  • 用户请求被定向到附近的站点，获取内容。
  • 当网络拥塞时，可向不同的站点请求内容拷贝。

CND内容访问案例
  Bob (client) 从 http://video.netcinema.com/6Y7B23V请求视频，且该视频保存在 KingCDN.com域中的一台服务器上。

访问过程：

  Netflix:

6. 套接字编程

6.1 基本概述

创建网络应用程序，需要：

• 编写一个客户程序、一个服务器程序。
• 客户和服务器可以利用套接字收、发报文。

套接字: 应用进程和传输层之间的"门"。

Socket API

• 1981年在BSD UNIX 4.1中引入，此后成为编写因特网程序的标准接口。
• 应用需显式地创建、使用和释放套接字。
• 采用客户-服务器模式。
• 应用通过socket API可以调用两种传输服务:
  • 不可靠的数据报服务：由UDP协议实现。
  • 可靠的字节流服务：由TCP协议实现。

6.2 UDP套接字编程

应用实例

1. 客户程序从键盘读入一行字符（数据），发送给服务器。
2. 服务器接收数据，将小写字符转换成大写字符。
3. 服务器将修改后的数据发送给客户。
4. 客户接收修改后的数据，在屏幕上显示出来。

套接字编程实例

服务器端：

客户端：客户端的端口号是操作系统来决定的，并不需要我们指定（人为写可能会写到被占用的端口号）。

6.3 TCP套接字编程

可将TCP连接想像成是一对套接字之间的一条封闭管道：

• 发送端TCP将要发送的字节序列从管道的一端（套接字）送入。
• 接收端TCP从管道的另一端（套接字）取出字节序列。
• 在管道中传输的字节不丢失，并保持顺序。
  
  服务器使用多个套接字服务客户
• 服务器进程在欢迎套接字上等待客户的连接请求。
• 客户进程需要通信时，创建一个客户套接字，与服务器欢迎套接字通信：
  • 在此过程中，客户TCP向服务器TCP发送连接请求。
• 服务器进程创建一个临时套接字（称连接套接字）和一个新的服务器进程，与客户进程通信。
• 服务器进程回到欢迎套接字上继续等待。
  • 允许服务器同时服务多个客户。
• 客户服务结束后，服务器销毁进程，关闭连接套接字。
  
  服务器端：
  
  客户端：
  

UDP服务与TCP服务的异同：

UDP	TCP
报文传输服务	字节流传输服务
由于没有建立管道，应用程序发送每个报文必须给出远程进程地址。	由于建立了管道，应用程序只需向套接字中写入字节序列，不需指出远程进程地址。
服务器使用一个进程和一个套接字为所有客户服务，一次请求-响应完成一次服务。	服务器为每个客户单独生成一个套接字和一个新进程，允许双方长时间通信。