Chapter 2 Application Layer

Presentation on theme: "Chapter 2 Application Layer"— Presentation transcript:

1 Chapter 2 Application Layer
A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: Computer Networking: A Top Down Approach 6th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!) If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved Application Layer

2 Chapter 2: Application Layer
Our goals: 学习网络应用的原理及实现方面的知识 几个重要的概念： 客户-服务器模式 对等模式 传输层服务 进程与传输层接口 几个流行的应用层协议： HTTP FTP SMTP / POP3 / IMAP DNS 开发网络应用程序： socket API 2: Application Layer

3 Chapter 2: outline 2.1 principles of network applications
2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 electronic mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P applications 2.7 socket programming with UDP and TCP Application Layer

4 创建一个网络应用 创建一个网络应用的核心，是编写一个分布式程序，使其可以： 应用程序只运行在终端上：
application transport network data link physical 创建一个网络应用的核心，是编写一个分布式程序，使其可以： 运行在不同的端系统上，并能通过网络相互通信 例如，web服务器软件与浏览器软件 应用程序只运行在终端上： 应用程序员不需要为网络核心设备编写程序 “只在端系统上开发应用”是一个非常重要的设计决定： 极大地方便了网络应用的开发和快速部署 application transport network data link physical application transport network data link physical 2: Application Layer

5 2.1.1 网络应用架构 在开发一个应用程序之前，首先要决定采用什么样的网络应用架构 网络应用架构规定了在各个端系统上组织应用程序的方法
目前有两种主流的网络应用架构： 客户-服务器架构（Client-server） 对等架构（Peer-to-peer ，P2P) 2: Application Layer

6 客户-服务器架构 服务器（server）: 客户（client）: 客户只与服务器通信，客户之间不通信
服务器主机(server machine)具有永久的、众所周知的地址 客户（client）: 用户终端上运行一个客户程序(client)，需要时与服务器程序通信，请求服务 客户机（client machine）使用动态地址，通常不会总是在线 client/server 客户只与服务器通信，客户之间不通信 2: Application Layer

7 P2P架构 没有总是在线的服务器主机 任意一对端系统（对等方）可以直接通信 对等方多为用户自己的计算机，使用动态地址
每个对等方既可请求服务，也可提供服务 典型的P2P应用： BT、迅雷 Skype PPLive peer-peer 2: Application Layer

8 两种架构的比较 P2P架构： 客户-服务器架构： 资源集中： 资源分散： 优点： 优点： 缺点： 缺点： 任何终端都可以提供资源（服务）
资源（服务）只在某些固定的终端上提供 优点： 资源发现简单 缺点： 集中式计算带来的问题，如服务端扩容压力、网络流量不均衡、响应延迟长 资源分散： 任何终端都可以提供资源（服务） 优点： 易于扩容、均衡网络流量 缺点： 资源发现困难，社会问题（版权、安全性等） 2: Application Layer

9 2.1.2 不同终端上的进程通信 进程: 主机上运行的程序 在分布式应用中，不同终端上的进程需要通信 进程通信的方法：
同一个主机内：进程间通信机制（OS提供） 在不同主机上：通过交换报文进行通信 在一次确定的通信会话中，总能标示一方为客户进程，另一方为服务器进程： 客户进程：主动发起请求的进程 服务器进程：接收请求的进程 2: Application Layer

10 进程与网络的接口：套接字（socket）
进程如何将报文送入网络，又如何从网络接收报文？ 设想在应用程序和网络之间存在一扇门（套接字）： 发送报文：发送进程将报文推到门外 门外的运输设施（因特网）将报文送到接收进程的门口 接收报文：接收进程打开门，即可收到报文 套接字是应用层和传输层的接口，也是应用程序和网络之间的API application application socket controlled by app developer process process transport transport controlled by OS network network link Internet link physical physical Application Layer

11 进程如何标识自己：进程编址 A: 不能，因为同一个主机上可能运行着许多进程 每个进程需要一个标识，以便其它进程能够找到它
Q: 可以用进程所在主机的地址来标识进程吗？ A: 不能，因为同一个主机上可能运行着许多进程 端口号：用于区分同一个主机上的不同进程 进程标识包括： 主机地址 与该进程关联的端口号 端口号的例子： 众所周知的端口号分配给服务器，成为服务的标识 比如，HTTP server使用端口80，Mail server使用端口25 2: Application Layer

12 2.1.3 应用需要什么样的传输服务? 在创建一个应用程序时，开发者需要选定一种传输服务 Throughput
有些应用（如多媒体）要求保证最低可用带宽 有些应用（称弹性应用） 可以适应各种可能的带宽 Data integrity 有些应用（如音视频）可以容忍一定程度的数据丢失 有些应用（如文件传输）要求完全可靠的数据传输 Timing 有些应用（如网络电话，交互式网络游戏）要求延迟保证 有些应用（如邮件传输）对延迟不敏感 Security 加密，数据完整性，…… 2: Application Layer

13 2.1.4 因特网能够提供的传输服务 因特网提供2种传输服务，分别用TCP和UDP协议实现 TCP service:
面向连接: 保证传输顺序 可靠传输：不出错 流量控制: 发送进程不会“压垮”接收进程 拥塞控制: 网络超载时抑制发送进程 不提供: 及时性，最低带宽保证，安全性 UDP service: 通过因特网接收和发送报文 不提供: 顺序保证，可靠传输，流量控制，拥塞控制，及时性，最低带宽保证，安全性 2: Application Layer

14 2.1.5 应用层协议 应用进程之间交换的报文是什么样的？ 应用层协议定义： 公共域协议: 专用协议: 报文类型： 报文语法: 报文语义
e.g., request, response 报文语法: 报文中的字段及其描述 报文语义 各字段中信息的含义 发送/响应报文应遵循的规则 公共域协议: 在RFC文档中定义 允许互操作 e.g., HTTP, SMTP 专用协议: e.g., Skype 2: Application Layer

15 小结 为创建一个新的网络应用，需要： 要求掌握的概念： 选择一种网络应用架构：客户-服务器 or P2P
选择一种网络服务：TCP or UDP 确定一个端口号 定义应用层协议 编写客户程序和服务器程序（调用套接字接口） 要求掌握的概念： 客户-服务器模型 网络应用编程接口 2: Application Layer

16 Chapter 2: outline 2.1 principles of network applications
app architectures app requirements 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 electronic mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P applications 2.7 socket programming with UDP and TCP Application Layer

17 Web应用画像 应用层资源：网页（web pages） 网络应用架构：客户-服务器架构 要求网络服务：TCP服务 端口号：80
客户：浏览器 服务器：web服务器 要求网络服务：TCP服务 端口号：80 应用层协议：HTTP 2: Application Layer

18 一些术语 Web page由一些对象（object）组成 对象简单来说就是文件，可以是HTML文件、图像、Java小程序、音频文件，…
Web页通常包含一个HTML基本文件和若干引用对象，比如，一个HTML文件和5个JPEG文件，共6个对象 每个对象通过一个URL (Uniform Resource Locator) 进行访问，例如： host name path name method 2: Application Layer

19 2.2.1 超文本传输协议--HTTP 概述 Web采用客户-服务器模式 client: 浏览器请求、接收和显示web对象
server: Web服务器应客户请求发送对象 HTTP协议：定义了浏览器和web服务器之间的通信规则 HTTP 1.0（RFC 1945）和HTTP 1.1（RFC 2068） HTTP request PC running Explorer HTTP response HTTP request Server running Apache Web server HTTP response Mac running Navigator 2: Application Layer

20 HTTP 使用TCP服务 客户发起到服务器 80 端口的 TCP 连接（客户端创建一个套接字） HTTP是“无状态的”
浏览器和服务器交换HTTP报文 （通过各自的套接字） 关闭TCP 连接（关闭各自的套接字） HTTP是“无状态的” 服务器不保存有关客户请求的任何信息 aside Protocols that maintain “state” are complex! past history (state) must be maintained if server/client crashes, their views of “state” may be inconsistent, must be reconciled 2: Application Layer

21 2.2.2 非持久连接和持久连接 非持久 HTTP 持久 HTTP 在一个TCP连接上最多发送一个对象 HTTP/1.0 使用非持久连接
2: Application Layer

22 非持久 HTTP (包含文本及 10个Jpeg图像) 假设用户输入以下URL： 1a. HTTP客户发起到以下HTTP 服务器进程的连接 on port 80 （建立TCP连接） 1b. 2. HTTP客户将一个HTTP请求报文（包含URL）写入它的套接字，报文指示希望获取以下对象：someDepartment/home.index （请求对象） 3. HTTP服务器接收请求报文，构造包含所请求对象的响应报文，将报文写入它的套接字中。 time 2: Application Layer

23 非持久HTTP（续） time 4. HTTP 服务器关闭TCP连接
5. HTTP 客户接收包含HTML文件的响应报文，显示HTML文件，解析文件发现有10个引用的jpeg对象 time 6. 对于每个jpeg对象，重复步骤 1-5 2: Application Layer

24 非持久HTTP的响应时间 RTT (Round-Trip Time): 一个小分组从客户发送到服务器，再返回客户的时间
Response time: 建立TCP连接用时一个RTT 发送HTTP请求至收到响应的前几个字节用时一个RTT 传输文件的时间 请求一个网页的时间： 请求一个对象用时2RTT（忽略对象传输时间） 请求一个完整的网页用时22RTT（11个对象） time to transmit file initiate TCP connection RTT request received time 2: Application Layer

25 持久 HTTP 非持久HTTP 的问题: 无流水线方式: 流水线方式: 持久 HTTP 获取每个对象需要2个RTT
每个TCP连接需要消耗操作系统资源 浏览器需要打开多个TCP连接来获取一个网页 持久 HTTP 服务器在发送响应后保持连接 同一对客户-服务器之间的后续HTTP报文可以在该连接上传输 无流水线方式: 客户仅当收到前一个响应后再发送新的请求 请求每个对象用时1个RTT 请求一个网页用时12RTT 流水线方式: HTTP/1.1缺省使用该方式 客户每解析到一个引用对象就可以发送请求 可在一个RTT时间内请求所有引用对象 请求一个网页用时约3RTT 2: Application Layer

26 2.2.3 HTTP 报文格式 两类HTTP报文: HTTP报文由ASCII文本构成 HTTP请求报文: 请求报文：客户发往服务器
响应报文：服务器发往客户 HTTP报文由ASCII文本构成 HTTP请求报文: 2: Application Layer

27 HTTP请求报文 报头包括： 请求行 GET /somedir/page.html HTTP/1.1
Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) 首部行 一个额外的回车换行表示报头结束 2: Application Layer

28 上传表单输入 Post 方法: Web页通常包含表单输入 输入的表单内容放在报文体中上传到服务器 URL 方法: 使用 GET 方法
2: Application Layer

29 HTTP方法 HTTP/1.0 HTTP/1.1 GET GET, POST, HEAD POST PUT HEAD
要求服务器不返回对象，只用一个报文头响应（实体为空），常用于故障跟踪。 HTTP/1.1 GET, POST, HEAD PUT 将文件放在报文实体中，传到URL字段指定的路径 DELETE 删除URL字段指示的文件 2: Application Layer

30 HTTP 响应报文 状态行 HTTP/1.1 200 OK Connection: close
Date: Thu, 06 Aug :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 ... 首部行 数据，如请求的 HTML文件 2: Application Layer

31 HTTP 响应状态代码 A few sample codes: 200 OK 301 Moved Permanently
request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported 2: Application Layer

32 Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server: telnet cis.poly.edu 80 Opens TCP connection to port 80 (default HTTP server port) at cis.poly.edu. Anything typed is sent to port 80 at cis.poly.edu 2. Type in a GET HTTP request: By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server GET /~ross/ HTTP/1.1 Host: cis.poly.edu 3. Look at response message sent by HTTP server! 2: Application Layer

33 Let’s look at HTTP in action
telnet example（自己试一下） Wireshark example（实验） 2: Application Layer

34 2.2.4 用户与服务器交互: cookie Example: 许多大型的Web网站都使用cookie Susan 总是从她的PC机上网
她第一次访问某个电子商务网站 当HTTP请求报文到达该网站时，网站为其创建: 一个ID 在后端数据库中为该ID建立一个表项 许多大型的Web网站都使用cookie Four components: 1) HTTP响应报文中的cookie首部行 2) HTTP请求报文中的cookie 首部行 3) 保存在用户主机的cookie文件，由用户的浏览器管理 4) Web网站的后端数据库 2: Application Layer

35 Cookies: 保存“状态” client server Amazon server creates ID 1678 for user
ebay 8734 usual http request msg Amazon server creates ID 1678 for user create entry cookie file usual http response Set-cookie: 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 cookie- specific action access usual http request msg cookie: 1678 cookie- spectific action access usual http response msg backend database one week later: ebay 8734 amazon 1678 usual http response msg 2: Application Layer

36 Cookies (continued) Cookies 和隐私: What cookies can bring:
aside Cookies 和隐私: Cookies允许网站收集用户的大量信息 you may supply name and to sites What cookies can bring: authorization shopping carts recommendations user session state (Web ) Where to keep “state”: 服务端：信息保存在服务端的后端数据库，返回ID给客户 客户端：信息发回客户端，保存在cookie文件中，并随请求报文发送给服务器 2: Application Layer

37 2.2.5 Web缓存（代理服务器） 代理服务器: 代表原始服务器满足HTTP请求的网络实体，保存最近请求过的对象的拷贝。
用户设置浏览器：所有HTTP请求首先发往web 缓存 浏览器将HTTP请求发送给web缓存： 对象在web缓存中: web缓存返回对象 对象不在web缓存中：web缓存从原始服务器获取对象，缓存在本地，然后返回给客户 origin server HTTP response Proxy server HTTP request client HTTP request HTTP response client origin server Q: web缓存如何知道对象的原始服务器？ 2: Application Layer

38 More about Web caching Web cache既是服务器又是客户：
对于浏览器来说是服务器 对于原始服务器来说是客户 Web cache通常由ISP提供，多级ISP可能形成多级web缓存 Why Web caching? 减少客户请求的响应时间 减少机构接入链路上的流量 2: Application Layer

39 Caching example Assumptions Consequences 平均对象长度 = 1Mb
从机构浏览器到原始服务器的平均请求速率 = 15/sec 从接入路由器到原始服务器的来回延迟（RTT）= 2 sec Consequences LAN利用率 = 15% 接入链路的利用率 = 100% total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds origin servers public Internet 15 Mbps access link institutional network 100 Mbps LAN 2: Application Layer

40 Caching example (cont)
origin servers possible solution 提高接入链路带宽至100Mbps consequence LAN利用率 = 15% 接入链路利用率 = 15% Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs 链路升级的代价高昂！ public Internet 100 Mbps access link institutional network 100 Mbps LAN 2: Application Layer

41 Caching example (cont)
possible solution： 安装web cache 假设cache命中率为 0.4 consequence 40%的请求可被立即满足 60%的请求被原始服务器满足 接入链路利用率为60%, 延迟为 ～10msecs total avg delay = Internet delay + access delay + LAN delay = 0.6*(~2.01 secs) *(~msecs) = ~ 1.2 secs 比升级链路的延迟还要低！ origin servers public Internet 15 Mbps access link institutional network 100 Mbps LAN institutional cache 2: Application Layer

42 If-modified-since: <date> If-modified-since: <date>
2.2.6 条件 GET 代理服务器如何发现缓存的对象是不是最新的？ cache server web cache: 在GET报文中包含以下首部行 If-modified-since: <date> server: 若发现对象无更新，响应报文中不包含对象: HTTP/ Not Modified server: 若发现对象有更新，响应报文中包含对象 HTTP request msg If-modified-since: <date> object not modified HTTP response HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> object modified HTTP response HTTP/ OK <data> 2: Application Layer

43 小结 因特网上的每个资源（对象）都可以通过URL访问 HTTP使用TCP连接 客户与服务器交互：
非持续HTTP 持续HTTP 客户与服务器交互： 报文请求/响应 HTTP服务器是无状态的，利用cookie技术可以保存用户状态 使用web缓存提高请求-响应速度： 使用条件get获得最新的对象副本 2: Application Layer

44 理解http及web技术的发展脉络 为什么HTTP最初设计为是非持久连接、无状态的？ 后来为什么引入持久连接？
为什么引入cookie技术，它带来什么问题？ 为什么引入web缓存技术，它带来什么问题，如何解决？ 2: Application Layer

45 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with UDP and TCP 2: Application Layer

46 文件传输应用画像 应用层资源：文件 网络应用架构：客户-服务器 使用传输服务：TCP 端口号：21、20 应用层协议：FTP
user interface client file transfer FTP server user at host remote file system local file system 应用层资源：文件 网络应用架构：客户-服务器 使用传输服务：TCP 端口号：21、20 应用层协议：FTP 使用命令/响应交互（不是像HTTP那样使用报文交互） 通常情况下，用户通过FTP用户代理与文件服务器交互 2: Application Layer

47 FTP用户代理 2: Application Layer

48 TCP control connection
使用分离的控制连接和数据连接 控制连接： 使用端口21，传送客户命令和服务器响应 控制连接在整个会话期间一直保持 数据连接： 使用端口20，传输文件 每个数据连接只传输一个文件，发送方用关闭连接表示一个文件传输结束 FTP client server TCP control connection port 21 TCP data connection port 20 2: Application Layer

49 建立控制连接 服务器在端口21等待客户 客户使用临时端口号建立连接

50 建立数据连接（主动模式） 客户选择一个临时端口号，在该端口上等待服务器的连接请求 客户在控制连接上用PORT命令将临时端口号发送给服务器
服务器使用端口20与客户机给出的端口建立连接

51 有关控制连接与数据连接的问题 Q：为什么将控制连接与数据连接分开？ Q：为什么用关闭数据连接的方式结束文件传输？
A：不会混淆数据与命令/响应，简化协议设计和实现； 在传输文件的过程中可以继续执行其它的操作，便 于控制传输过程（如客户可以随时终止传输） Q：为什么用关闭数据连接的方式结束文件传输？ A：允许动态创建文件（不需预先告知文件的大小）

52 FTP小结 使用TCP协议，服务器端口号21、20 采用命令/响应交互方式 使用两条TCP连接： 要求理解：
控制连接（端口21）：会话期间始终保持 数据连接（端口20）：每条连接仅传输一个文件，客户与服务器角色交换 要求理解： 为什么使用两条分开的连接，即为什么不在同一条连接上既传输命令/响应，又传输数据？ 为什么每条数据连接只传输一个文件？ 2: Application Layer

53 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with UDP and TCP 2: Application Layer

54 电子邮件应用画像 应用层传输对象：邮件 网络应用架构：客户-服务器架构 要求网络服务：TCP服务 应用层协议：
邮件传输协议：SMTP（端口号25） 邮件访问协议：POP（端口号），IMAP（端口号），HTTP（端口号80） SMTP、POP、IMAP采用命令/响应交互 2: Application Layer

55 2.4.1 电子邮件系统 最初由三个部分组成: 用户代理 邮件服务器 简单邮件传输协议 SMTP SMTP SMTP outgoing
user mailbox outgoing message queue user agent 最初由三个部分组成: 用户代理 邮件服务器 简单邮件传输协议 mail server user agent SMTP mail server user agent SMTP mail server SMTP user agent user agent user agent 2: Application Layer

56 用户代理 编辑、阅读、回复邮件等 将要外发的邮件发送到用户的邮件服务器 从用户邮箱中取邮件 一些用户代理： SMTP SMTP SMTP
user mailbox outgoing message queue user agent 编辑、阅读、回复邮件等 将要外发的邮件发送到用户的邮件服务器 从用户邮箱中取邮件 一些用户代理： Outlook, elm, Mozilla, Thunderbird mail server user agent SMTP mail server user agent SMTP mail server SMTP user agent user agent user agent 2: Application Layer

57 邮件服务器 邮件服务器上包含： 用户信箱：存放到来的邮件 发送报文队列：存放要发送出去的邮件
user mailbox outgoing message queue user agent 邮件服务器上包含： 用户信箱：存放到来的邮件 发送报文队列：存放要发送出去的邮件 报文传输代理MTA：运行在服务器后台的系统守护进程，负责在邮件服务器之间传输邮件，及将收到的邮件放入用户信箱。 mail server user agent SMTP mail server user agent SMTP mail server SMTP user agent user agent user agent 2: Application Layer

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

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

60 Scenario: Alice sends message to Bob
1) Alice使用用户代理编辑邮件，发送给 2) Alice的用户代理将报文发送给其邮件服务器（使用SMTP） 3) 邮件被置于邮件服务器的发送报文队列中 4) Alice的邮件服务器与Bob的邮件服务器建立TCP连接，然后发送 Alice的邮件 5) Bob的邮件服务器将邮件放置在Bob的信箱中 6) Bob调用他的用户代理阅读邮件 mail server mail server 1 user agent user agent 2 3 6 4 5 2: Application Layer

61 邮件传送阶段（1） 连接与握手： MTA客户与MTA服务器在端口25建立TCP连接。 服务器发送服务就绪报文
客户发送HELO报文，用域名标识自己 服务器响应

62 邮件传送阶段（2） 2: Application Layer

63 邮件传送阶段（3） 结束传输 客户发送QUIT报文 服务器响应 释放TCP连接

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

65 2.4.2 邮件报文格式 RFC 822规定了邮件报文格式 报头由一些首部行组成，如： 实体: 只能使用简单ASCII字符 header
To: From: Subject: 实体: 只能使用简单ASCII字符 header blank line body Application Layer

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

67 Base64编码 Base64用来将一个二进制字节序列转换成由ASCII字符序列构成的文本。
0～25编码成‘A’～‘Z’ 26～51编码成‘a’～‘z’ 52～61编码成‘0’～‘9’ 62和63分别编码成‘＋’和‘／’ 若最后一组只有8比特或16比特，分别加上‘＝＝’和‘＝’后缀 回车和换行忽略，可以插在任何地方

68 Base64编码示例

69 quoted-printable编码 适用于绝大部分都是ASCII字符的报文实体，其编码方法是： 每个ASCII字符保持不变

70 quoted-printable编码示例

71 多用途因特网邮件扩展协议MIME 扩展了RFC 822，允许实体具有不同的数据类型，并规定了非ASCII文本信息在传输时的统一编码形式
扩充了一些首部行，最重要的是： Content-Transfer-Encoding：实体采用的传输编码形式 Content-Type：实体的数据类型及子类型

72 MIME报文格式 [RFC 2045, 2056] MIME version method used to encode data
From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data 2: Application Layer

73 2.4.3 邮件访问 邮件访问方式： 早期：用户登陆到邮件服务器上，直接在服务器上运行一个邮件阅读程序来阅读邮件
今天：用户在终端上安装用户代理，获取和阅读邮件 Q：能将用户信箱放在本地终端吗？ A：不能，用户终端不可能一直连在因特网上 Q：能用SMTP从邮件服务器中获取邮件吗？ A：不能，SMTP是一个“推”协议，只能将邮件从用户代理推送到其邮件服务器。 解决方案：设计一个新的协议从服务器获取邮件 2: Application Layer

74 邮件的两阶段交付 SMTP SMTP access protocol
user agent 在具有永久因特网连接的计算机上运行一个SMTP服务器，为用户分配一个永久信箱。 第一阶段：邮件被投递到收信人的永久信箱。 第二阶段：用户从永久信箱中获取邮件。 带永久信箱的计算机必须运行两个服务器程序： SMTP服务器：接收用户邮件，放入用户信箱。 邮件访问服务器：允许用户从信箱中提取邮件。 user agent sender’s mail server receiver’s mail server

75 邮件访问协议 可以从服务器获取邮件的协议有： 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. 2: Application Layer

76 POP3 protocol 认证和授权阶段 C: list 事务阶段 客户命令: user: declare username
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on 认证和授权阶段 客户命令: user: declare username pass: password 服务器响应 +OK -ERR 事务阶段 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> C: dele 1 C: retr 2 C: dele 2 C: quit S: +OK POP3 server signing off 2: Application Layer

77 POP3 (more) and IMAP IMAP More about POP3 所有邮件保存在服务器上
前一个例子使用了“download and delete” 模式，在另一台终端上无法再获取邮件 “Download-and-keep”模式可将邮件保留在服务器中 IMAP 所有邮件保存在服务器上 允许用户将邮件组织在文件夹中 允许用户在文件夹之间移动邮件 2: Application Layer

78 基于web的邮件访问：HTTP 用户代理为普通浏览器: 和IMAP一样，用户可以在远程服务器上用文件夹来组织他们的邮件。
发送邮件：浏览器使用HTTP协议将邮件发送到邮件服务器 获取邮件：浏览器使用HTTP协议从信箱取邮件 传输邮件：邮件服务器之间仍使用SMTP协议传输报文 和IMAP一样，用户可以在远程服务器上用文件夹来组织他们的邮件。

79 现代因特网电子邮件系统的组成 用户代理 邮件服务器 简单邮件传输协议SMTP 邮件访问协议（POP，IMAP，HTTP）

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

81 理解HTTP、FTP、SMTP设计上的不同
HTTP、FTP、SMTP均是在TCP连接上传输文件，但是在设计上有一些不同 使用持久连接或非持久连接： HTTP可在一条TCP连接上传输多个对象，SMTP可以传输多个邮件，FTP只传输一个文件 文件传输结束的标记： HTTP使用长度指示报文结束，FTP使用关闭连接表示文件结束，SMTP 使用“.”表示报文结束 文件中的内容要求： SMTP要求邮件只包含简单ASCII文本，FTP和HTTP无此要求（为此，SMTP在传输其它类型内容时需要有特殊处理） HTTP采用报文交互，SMTP和FTP采用命令/响应交互 Web和文件传输只使用一种应用层协议，电子邮件使用邮件传输和邮件访问两种协议

82 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with UDP and TCP 2: Application Layer

83 DNS: Domain Name System
因特网主机需要标识: IP地址（32 bit）– 由机器使用 名字，如 – 由人类使用，便于记忆 Q: 如何提供主机名到IP地址的映射? 因特网的目录服务DNS： 将主机名映射到IP地址 DNS实现为一个应用层服务： 由其它应用使用 客户-服务器模式 请求/响应报文交互 主要使用UDP协议，端口号53 2: Application Layer

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

85 2.5.2 DNS工作机理 将主机名转换成IP地址： ** 对应用程序而言，DNS是一个提供直接转换服务的黑盒子
应用程序（如浏览器）调用一个本地例程（解析器），主机名作为参数之一传递 解析器向网络中的DNS服务器发送查询报文，包含要查询的主机名 解析器收到包含IP地址的响应报文 解析器将IP地址返回给调用者（如浏览器） ** 对应用程序而言，DNS是一个提供直接转换服务的黑盒子 2: Application Layer

86 DNS采用分布式结构 Q: 为什么不使用集中式的DNS？ 单点失效 流量集中：单个DNS服务器需处理全部查询
响应时间长：远距离的集中式数据库 需要维护庞大的数据库 A: Doesn’t scale! Application Layer

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

88 域名 域（domain）： 标记（label）： 域名（domain name）：
名字树中一个特定的节点以及该节点下所有的节点构成一个域 标记（label）： 树上每一个节点都有一个标记（最多63个字符），树根的标记是一个空字符串 域名（domain name）： 某个域的名字表示为：从该域开始向上直到树根的标记序列，标记之间用句点隔开（类似国外邮政地址的写法） 域名的任一后缀也是一个域，同一个机构内的主机具有相同的域名后缀 每个节点只需保证其孩子节点的标记不重名 2: Application Layer

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

90 组织域 由美国国内及一些国际组织使用

91 国家域 使用二字符的国家代码，每个国家对应一个

92 反向域 域名为arpa，用来把一个IP地址映射为名字 例如： 反向域名解析是为了溯源
IP地址 表示为： in-addr.arpa 反向域名解析是为了溯源 2: Application Layer

93 域名服务器的组织层次 客户想知道www.amazon.com的IP地址: DNS客户查询根服务器，得到com域的DNS服务器地址
Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org 客户想知道 DNS客户查询根服务器，得到com域的DNS服务器地址 DNS客户查询com域的DNS服务器，得到amazon.com域的DNS服务器地址 DNS客户查询amazon.com域的DNS服务器，得到 2: Application Layer

94 根域名服务器 全球有13个根服务器（每个根服务器是一个服务器集群） 根服务器知道所有顶级域服务器的IP地址
a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus other locations) e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Application Layer

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

96 本地DNS服务器 严格来说，本地DNS服务器不属于DNS服务器的层次结构 每个ISP都有一台本地DNS服务器，也称“默认的DNS服务器”
2: Application Layer

97 authoritative DNS server
域名解析的例子 root DNS server cis.poly.edu上的一台主机想知道 gaia.cs.umass.edu的IP地址 2 3 TLD DNS server 4 5 local DNS server dns.poly.edu 迭代查询: 收到查询报文的服务器将下一个需要查询的服务器地址返回给查询者 “I don’t know this name, but ask this server” 7 6 1 8 authoritative DNS server dns.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 2: Application Layer

98 authoritative DNS server
域名解析的例子 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 4 5 6 authoritative DNS server dns.umass.edu 7 8 TLD DNS server 3 递归查询: puts burden of name resolution on contacted name server heavy load? 2: Application Layer

99 DNS zone 整个DNS名字空间被划分成一些不重叠的区域，称为DNS zone，每个zone包含域名树的一部分。

100 物理服务器的层次 一个物理服务器保存的信息可能涉及域名空间的若干层，它也可以把它的域划分成若干子域，把其中的一些子域委托给其它服务器
实际的物理服务器的层次与域名空间的逻辑层次不同

101 DNS缓存 每当收到一个响应报文，DNS服务器将报文中的映射信息缓存在本地。 DNS服务器首先使用缓存中的信息响应查询请求
特别地，本地DNS服务器通常会缓存TLD服务器的IP地址，因而很少去访问根服务器 2: Application Layer

102 RR format: (name, type, ttl, value)
2.5.3 DNS资源记录 DNS更准确的说法: 存储资源记录（RR）的分布式数据库 RR format: (name, type, ttl, value) Type=A Name：主机名 Value：IP地址 Type=CNAME Name：别名 Value：规范名 Type=NS Name：域 (e.g. foo.com) value：该域的权威DNS服务器的主机名 Type=MX Name：域(e.g. foo.com) Value：该域的邮件服务器名字 2: Application Layer

103 DNS数据库内容示例

104 2.5.4 DNS协议，报文 DNS协议: 定义了查询和响应两种报文，查询和响应使用相同的报文格式 报头
identification: 16 bit # for query, reply to query uses same # flags: query or reply recursion desired (q) recursion available (r) reply is authoritative 2: Application Layer

105 DNS协议，报文 Name, type fields for a query RRs in response to query
records for authoritative servers additional “helpful” info that may be used 2: Application Layer

106 DNS报文的封装 DNS可以使用UDP，也可以使用TCP，服务器的熟知端口都是53 当响应报文的长度小于512字节时，使用UDP
当解析器事先不知道响应报文的长度时，先使用UDP；若响应报文的长度超过512字节，服务器截断这个报文，置DNS报文首部的TC标志为1；解析程序打开TCP连接，并重复这个请求，以便得到完整的响应

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

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

109 思考 为什么DNS主要使用UDP服务，什么时候及为什么使用TCP服务？ DNS缓存可能引入哪些问题 DNS面临的安全问题
2: Application Layer

110 Chapter 2: Application layer
2.1 Principles of network applications app architectures app requirements 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with UDP and TCP 2: Application Layer

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

112 P2P: 集中式目录 original “Napster” design
centralized directory server peers Alice Bob 1 2 3 original “Napster” design 1) when peer connects, it informs central server: IP address content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob

113 P2P: 集中式目录的问题 single point of failure performance bottleneck
copyright infringement: “target” of lawsuit is obvious file transfer is decentralized, but locating content is highly centralized

114 Query flooding: Gnutella
fully distributed no central server public domain protocol many Gnutella clients implementing protocol overlay network: graph edge between peer X and Y if there’s a TCP connection all active peers and edges form overlay net edge: virtual (not physical) link given peer typically connected with < 10 overlay neighbors

115 Gnutella: protocol Query message sent over existing TCP connections
File transfer: HTTP Query message sent over existing TCP connections peers forward Query message QueryHit sent over reverse path Query QueryHit Scalability: limited scope flooding

116 Gnutella: Peer joining
joining peer Alice must find another peer in Gnutella network: use list of candidate peers Alice sequentially attempts TCP connections with candidate peers until connection setup with Bob Flooding: Alice sends Ping message to Bob; Bob forwards Ping message to his overlay neighbors (who then forward to their neighbors….) peers receiving Ping message respond to Alice with Pong message Alice receives many Pong messages, and can then setup additional TCP connections

117 Hierarchical Overlay between centralized index, query flooding approaches each peer is either a group leader or assigned to a group leader. TCP connection between peer and its group leader. TCP connections between some pairs of group leaders. group leader tracks content in its children

118 比较客户-服务器和P2P架构 Question : 将文件从一台服务器分发到网络中的N个终端，需要多少时间？ us: 服务器上传带宽
Server ui: 第 i 个终端的上传带宽 u1 d1 u2 d2 us di: 第 i 个终端的下载带宽 File, size F dN Network (with abundant bandwidth) uN

119 客户-服务器架构的文件分发时间 服务器顺序地发送N 个文件拷贝，耗时: NF/us 第 i 个客户花费F/di 下载文件 将文件F分发给
Server 服务器顺序地发送N 个文件拷贝，耗时: NF/us 第 i 个客户花费F/di 下载文件 F u2 u1 d1 d2 us Network (with abundant bandwidth) dN uN = dcs = max { NF/us, F/min(di) } i 将文件F分发给 N 个客户耗时 increases linearly in N (for large N)

120 P2P架构的文件分发时间 服务器至少必须发送一个拷贝，耗时F/us 第 i 个客户至少耗时F/di下载文件
Server 服务器至少必须发送一个拷贝，耗时F/us 第 i 个客户至少耗时F/di下载文件 总共NF bits 必须在网络中被下载 F u2 u1 d1 d2 us Network (with abundant bandwidth) dN uN 网络中总的上传带宽为: us + Sui i=1,N dP2P = max { F/us, F/min(di) , NF/(us + Sui) } i i=1,N

121 文件分发时间比较 假设： 客户-服务器架构： P2P架构：
客户的上传带宽均为u，F/u=1 hour，us=10u，dmin>us（下载速率不是瓶颈） 客户-服务器架构： 分发时间随N线性增大 P2P架构： 最小分发时间总是小于客户-服务器架构 对于任意的N，最小分发时间总是小于1小时

122 P2P案例学习: BitTorrent tracker: 对等方加入洪流： Torrent（洪流）: 参与一个特定文件分发的对等方集合
跟踪洪流中的对等方 Torrent（洪流）: 参与一个特定文件分发的对等方集合 obtain list of peers trading chunks peer 对等方加入洪流： 向跟踪器注册，获得一个对等方列表 尝试向列表中的对等方建立TCP连接 2: Application Layer

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

124 BitTorrent (操作) Pulling Chunks Sending Chunks: tit-for-tat
在任何给定时刻，不同的对等方拥有不同的数据块子集 周期性地，对等方（如Alice）询问每个邻居他们拥有的数据块集合 Alice向邻居请求她缺少的数据块： 最稀罕优先：优先请求在邻居中拷贝数量最少的数据块 Sending Chunks: tit-for-tat Alice选择当前向其发送数据最快的4个邻居，响应他们的数据块请求 每隔10秒，重新评估向其提供数据最快的4个邻居 每隔30秒，随机选择另一个对等方（如Bob）响应其请求 Alice可能成为向Bob上载最快的4个邻居之一 Bob也可能成为向Alice上载最快的4个邻居之一 2: Application Layer

125 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 File Transfer and FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with UDP and TCP 2: Application Layer

126 套接字编程 创建网络应用程序，需要： 套接字: 应用进程和传输层之间的“门” 编写一个客户程序、一个服务器程序
客户和服务器可以利用套接字收、发报文 套接字: 应用进程和传输层之间的“门” Internet controlled by OS controlled by app developer transport application physical link network process socket 2: Application Layer

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

128 本节使用的一个应用例子 客户程序从键盘读入一行字符（数据），发送给服务器 服务器接收数据，将小写字符转换成大写字符
服务器将修改后的数据发送给客户 客户接收修改后的数据，在屏幕上显示出来 Application Layer

129 server (running on serverIP)
2.7.1 UDP套接字编程 创建套接字 clientSocket 用serverIP 和端口x创建UDP报文 交给clientSocket server (running on serverIP) client 在端口x上创建套接字 serverSocket 从serverSocket 读UDP报文 关闭clientSocket 从clientSocket 读UDP报文 写UDP响应报文到 serverSocket Application

130 Example app: UDP server
Python UDPServer from socket import * serverPort = 12000 serverSocket = socket(AF_INET, SOCK_DGRAM) serverSocket.bind(('', serverPort)) print “The server is ready to receive” while 1: message, clientAddress = serverSocket.recvfrom(2048) modifiedMessage = message.upper() serverSocket.sendto(modifiedMessage, clientAddress) create UDP socket bind socket to local port number 12000 loop forever Read from UDP socket into message, getting client’s address (client IP and port) send upper case string back to this client Application Layer

131 Example app: UDP client
Python UDPClient include Python’s socket library from socket import * serverName = ‘hostname’ serverPort = 12000 clientSocket = socket(socket.AF_INET, socket.SOCK_DGRAM) message = raw_input(’Input lowercase sentence:’) clientSocket.sendto(message,(serverName, serverPort)) modifiedMessage, serverAddress = clientSocket.recvfrom(2048) print modifiedMessage clientSocket.close() create UDP socket for server get user keyboard input Attach server name, port to message; send into socket read reply characters from socket into string print out received string and close socket Application Layer

132 2.7.2 TCP套接字编程 可将TCP连接想像成是一对套接字之间的一条封闭管道： 发送端TCP将要发送的字节序列从管道的一端（套接字）送入
在管道中传输的字节不丢失，并保持顺序 controlled by application developer process TCP with buffers, variables socket process TCP with buffers, variables socket 由应用开发者控制 controlled by operating system 由操作系统控制 internet host or server host or server 2: Application Layer

133 服务器使用多个套接字服务客户 服务器进程在欢迎套接字上等待客户的连接请求
客户进程需要通信时，创建与服务器欢迎套接字通信的客户套接字： 在此过程中，客户TCP向服务器TCP发送连接请求 服务器进程创建一个临时套接字（称连接套接字）和一个新的服务器进程，与客户进程通信 服务器进程回到欢迎套接字上继续等待 允许服务器同时服务多个客户 客户服务结束后，服务器销毁进程，关闭连接套接字 2: Application Layer

134 Server (running on hostid)
客户-服务器交互：TCP Server (running on hostid) Client 在端口x上创建欢迎套接字： welcomeSocket = ServerSocket() 创建本地套接字 clientSocket = Socket() TCP connection setup 等待连接请求 连接到 hostid, port=x connectionSocket = welcomeSocket.accept() 使用clientSocket 发送服务请求 从connectionSocket 读服务请求 写响应到 connectionSocket 关闭connectionSocket 从clientSocket读响应 关闭clientSocket 2: Application Layer

135 Example app: TCP server
Python 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() create TCP welcoming socket server begins listening for incoming TCP requests loop forever server waits on accept() for incoming requests, new socket created on return read bytes from socket (but not address as in UDP) close connection to this client (but not welcoming socket) Application Layer

136 Example app: TCP client
Python TCPClient from socket import * serverName = ’servername’ serverPort = 12000 clientSocket = socket(AF_INET, SOCK_STREAM) clientSocket.connect((serverName,serverPort)) sentence = raw_input(‘Input lowercase sentence:’) clientSocket.send(sentence) modifiedSentence = clientSocket.recv(1024) print ‘From Server:’, modifiedSentence clientSocket.close() create TCP socket for server, remote port 12000 No need to attach server name, port Application Layer

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

138 Chapter 2: Summary 应用架构 应用服务需求:
client-server P2P 应用服务需求: reliability, bandwidth, delay, security 因特网传输服务模型 面向连接，可靠: TCP 不可靠，数据报: UDP 应用典型地采用请求/响应方式进行交互: 客户请求信息或服务 服务器用数据或状态码进行响应 报文格式： 报头: 携带元数据 实体: 携带数据本身 套接字编程： TCP UDP 2: Application Layer

139 作业 习题：1，3，7，8，9 HTTP实验 DNS实验 作业提交时间： 习题：25日 HTTP实验：18日 DNS实验：25日
2: Application Layer

140 课外拓展 提交： 从问题1、2、4中选择感兴趣的，写成PPT，10月7日前发给主讲老师 了解什么是web 1.0和web2.0。
内容分发网络（Content Delivery Network，CDN）为何能加快内容请求的速度？ 查看一下本机浏览器中的cookie文件（不需要交） 介绍1~2种与DNS相关的网络攻击，它们是怎么做到的？（可以是针对DNS系统进行的攻击，也可以是利用DNS服务实施的攻击） 提交： 从问题1、2、4中选择感兴趣的，写成PPT，10月7日前发给主讲老师 2: Application Layer