计算机网络Web应用层与运输层（HTTPTCP）

计算机⽹络Web应⽤层与运输层（HTTPTCP）

应⽤层协议原理

Web和HTTP

DNS:英特⽹的⽬录服务

运输层

⾯向连接的运输：TCP及拥塞原理

⼀、应⽤层协议原理

DNS域名解析：

(⽤例：)域名解析是⽹络请求的第⼀步操作，DNS域名解析⾸先是在浏览器缓存中匹配历史对应域名的IP地址，如果没有找到就到计算机的⽹络访问缓存中匹配，如果还找不到匹配的IP地址，就会将域名发送到根权威服务器上（com），然后再根权威服务器上匹配到域名（baidu）的服务器IP地址返回发送回客服端上。

⽹络连接实质上是基于IP地址来建⽴⽹络连接，最后实现数据传送。⽐如我们可以通过控制台然后使⽤ping命令查看到的IP 地址，然后可以直接将IP地址输⼊⽹址栏，照样可以获取到百度的主页。例如：

这⾥主要就⽹络访问⼀些过程做⼀些说明，后⾯有对DNS有具体的解析

有了IP地址，相当于才能真正找到服务器，IP作为每台⽹络计算机的唯⼀标识。这时候开始尝试建⽴⽹络通路，实现数据传输，也就有了三次握⼿和四次挥⼿的环节。⽹络应⽤通信的实际上进程，web应⽤是由客户端的浏览器进程和web服务器的进程交换报⽂。

套字节：即软件接⼝向⽹络发送报⽂和从⽹络接收报⽂。套字节是同⼀台主机内应⽤层与运输层的接⼝，由于该套字节是建⽴⽹络应⽤程序的可编程接⼝，因此套字节也是应⽤程序和⽹络之间的应⽤程序编程接⼝。应⽤程序开发者可以控制套字节在应⽤层端的⼀切，但是对该套字节的运输层端⼏乎没有控制权。应⽤程序开发者对于运输层的控制权仅限于：1.选择运输层协议；2.也许能设定⼏个运输层参数，如最⼤缓存和最⼤报⽂段长度等。(《计算机⽹络》59页)

除了将报⽂发送到⽬标服务器，还必须指定运⾏在接受主机上的接收进程。也可以说是端⼝号。通常web服务器端⼝号⽤80来标识。

可供应⽤程序使⽤的运输服务：

可靠数据传输：发送进程只要将其数据传递进套字节，就可以完全相信该数据将能⽆差错地到达接收进程。(数据不丢失)

吞吐量：运输层协议能够以某种特定的速率提供确保的可⽤吞吐量，使⽤这种服务能够确保可⽤吞吐量总是为⾄少r⽐特/秒（带宽敏感应⽤：(例)⽹络电话）；弹性应⽤能够根据情况或多或少地利⽤可供使⽤的吞吐量。电⼦邮件、⽂件传输、以及web传送都属于弹性应⽤。

定时：运输层能提供定时保证(时间敏感)。因特⽹电话、虚拟环境、电话会议和多⽅游戏都需要严格的事件限制。

安全性：运输协议能够为应⽤程序提供⼀种或多种安全性服务。（对发送进程传输的所有数据加密）

因特⽹（⼀般是TCP/IP⽹络）为应⽤提供两层运输协议，即UDP和TCP。下⾯是常见应⽤程序的服务要求：

应⽤数据丢失带宽时间敏感

⽂件传输不能丢失弹性不

电⼦邮件不能丢失弹性不

Web⽂档不能丢失弹性（⼏kbps）不

因特⽹电话/视频会议容忍丢失⾳频(⼏kbps~1Mbps)/视频

(10kbps~5Mbps)

是，100ms

存储⾳频/视频容忍丢失⾳频(⼏kbps~1Mbps)/视频

(10kbps~5Mbps)

是，⼏秒

交互式游戏容忍丢失⼏kbps~10kbps是，100ms

即时通讯不能丢失弹性是和不是

TCP服务：1.⾯向连接的服务：在应⽤层数据报⽂开始流动之前，TCP让客户和服务器相互交换运输层控制信息。这就是握⼿过程，这条连接是双⼯的，即连接双⽅的进程可以在此连接上同时进⾏报⽂收发。当应⽤程序结束报⽂发送时，必须拆除该链接，也就是挥⼿过程。2.可靠的数据服务，也就是数据层的可靠数据传输。然后，TCP协议还具有拥塞控制机制，这种服务不⼀定能为通信进程带来直接好处，但能为因特⽹带来整体好处。当发送⽅和接受⽅之间的⽹络出现拥塞时，TCP的拥塞控制机制会抑制发送进程(客户端或服务器)。

UDP服务：是⼀种不提供不必要服务的轻量级运输协议，它仅提供最⼩服务。UDP是⽆法连接，两个进程通信前没有握⼿过程。当进程将⼀个报⽂发送进UDP套字节时，UDP协议并不保证该报⽂将到达接受进程，并且到达接收进程的报⽂也可能是乱序到达。UDP没有拥塞机制，所以UDP的发送端可以⽤选定的任何速率向其下层注⼊数据(实际端到端吞吐量可能⼩于这个速率，这可能是因为中间链路的带宽受限或因为拥塞⽽造成的)。

因特⽹运输协议不提供的服务：吞吐量和定时保证，但不意味着因特⽹电话这样的时间敏感应⽤不能运⾏在因特⽹上，因为因特⽹上运⾏时间敏感应⽤已经有多年了(以后有机会对多媒体⽹络这部分重点分析：)。

流⾏的因特⽹引⽤及其应⽤层协议和⽀撑的运输协议：

应⽤⽤户层协议⽀撑的运输层协议电⼦邮件 SMTP [RFC 5321] TCP

远程终端访问 Telnet [RFC 854] TCP

Web HTTP [RFC 2616] TCP

⽂件传输 FTP [RFC 959] TCP

流式多媒体 HTTP(如YouTube) TCP

因特⽹电话 SIP [RFC 3261]、RTP

[RFC 3550]、或专⽤的（如

Skype)

UDP或TCP

⼆、Web和HTTP协议

Web的应⽤层协议是超⽂本传输协议(HyperText Transfer Protocol,HTTP)，它是Web的核⼼，在[RFC 1945]和[RFC 2616]中进⾏了定义。HTTP有两个程序实现：⼀个客户端程序和⼀个服务器程序。客户程序和服务器程序运⾏在不同的端系统中，通过交换HTTP报⽂进⾏会话。HTTP定义了这些报⽂的结构以及客户和服务器进⾏报⽂交换的⽅式。因为HTTP服务器并不保存关于客户的任何信息，假如某个特定的客户在短短⼏秒钟内两次请求同⼀个对象，服务器也响应两次，将同⼀个对象重复发送给客户，所以HTTP是⼀个⽆状态协议。

持续连接与⾮持续连接：

客户和服务器在⼀个相当长的时间范围内通信，其客户发出⼀系列请求并且服务器对每个请求进⾏响应。这⼀系列的请求可以以规则的间隔周期性地或者间断性地⼀个接⼀个发出。当客户与服务的交互时，每个请求/响应是经单独的TCP连接发送还是所有请求即响应都是经过相同的⼀个TCP连接发送。每个单独的TCP连接被称为⾮持续连接，经过相同的⼀个TCP连接被称为持续连接，持续连接在⼀定时间内没有发⽣请求HTTP服务器就会关闭连接。HTTP能够使⽤⾮持续连接也能使⽤持续连接，各有优缺点。

每⼀个HTTP请求都需要经过三次握⼿建⽴连接传输⽂件，这个过程需要两次往返时间(RTT),会产⽣⼀定的⽹络延时。持续连接可以在⼀定程度上减少这种重复的握⼿连接过程，但是多个请求采⽤⼀个TCP连接需要等待⼀个⼀个的传输，在⼀定程度上可以减少⽹络延时，但也产⽣了等待执⾏的时间。持续连接相对⾮持续连接在很⼤程度上减少了服务器的压⼒，但是性能问题是由多种因素造成的，量化⽐较持续连接和⾮持续连接对于优化性能⾮常有必要(《计算机⽹络》69页)参考⽂献[Heidemann 1997; Nielsen 1997]。

这就是常说的三次握⼿过程，这个过程我们需要重点关注的是往返时间（RTT）和传输⽂件的时间，这也是web开发中优化的重要部分。第⼀次握⼿：客服端发起TCP连接；第⼆次握⼿：服务端响应连接；第三次握⼿：客服端请求⽂件；接下来就是服务端响应⽂件请求，开始⽂件传输。

HTTP报⽂：

GET /somedir/page.html HTTP/1.1

Host:

Connection: close

User-agent:Mozilla/5.0

Accept-language: fr

报⽂使⽤普通的ASCII⽂本书写的，上⾯是个请求报⽂内容总共就5⾏代码，每⾏由⼀个回车和换⾏符结束，最后⼀⾏后⼀⾏后再附加⼀个回车换⾏符。第⼀⾏叫做请求⾏，第⼆⾏叫做⾸部⾏，Connection表⽰连接⽅式，User-agent⽤来指明代理，Accept-language表⽰想获得对象的语法版本。

请求⾏三个字段：⽅法字段、URL字段、HTTP版本字段。⽅法字段可取⼏种不同的值，包括GET、POST、HEAD、PUT和DELETE。URL字段带有请求对象的标识(page.html)，这⾥的版本字段实现的是HTTP/1.1版本。

⾸部⾏Host指明了对象所在的主机，⾸部提供的信息是Web代理⾼速缓存所要求的。其他的部分再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:Tue, 09 Aug 2011 15:11:03 GMT

Content-length:6821

Content-Type:text/html

(data data data data data ...)

响应报⽂的第⼀⾏是状态⾏，然后是⾸部(这⾥⾸部共六⾏)，然后是实体(响应实体)。

状态⾏三个字段：协议版本字段、状态码字段、相应状态信息。这⾥重点提⼀下状态码和相应状态信息，然后响应⾸部到HTTP协议分析博客中具体介绍。下⾯是⼀些常见的状态码和相关的短语：

200 OK:请求成功，信息在返回的响应报⽂中。

301 Moved Permanently:请求的对象已经被永久转移了，新的URL定义在响应报⽂的Location:⾸部中。客户软件将⾃动获取新的URL。