TCP/IP(Transmission Control Protocol/InternetProtocol。传输控制协议/网际协议)是用于计算机通信的一个协议族。 TCP/IP协议族包含诸如Internet协议(IP)、地址解析协议(ARP)、互联网控制信息协议(ICMP)、用户数据报协议(UDP)、传输控制协议(TCP)、路由信息协议(RIP)、Telnet、简单邮件传输协议(SMTP)、域名系统(DNS)等协议。

1. 应用层 应用层包括一切与应用相关的功能，我们常常使用的HTTP、FTP。Telnet、SMTP等协议都在这一层实现。

2. 传输层 传输层负责提供可靠的传输服务。在该层中。典型的协议是TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)。当中，TCP提供可靠、有序的，面向连接的通信服务。而UDP则提供无连接的、不可靠用户数据报服务。

3. 网际层 网际层负责网络间的寻址和传输数据，在该层中，典型的协议是IP(Internet Protocol)。

4. 网络接口层 最以下一层是网络接口层。负责数据的实际传输.网络接口层在发送端将上层的IP数据报封装成帧后发送到网络上。数据帧通过网络到达接收端时。该结点的网络接口层对数据帧拆封，并检查帧中包括的MAC地址。假设该地址就是本机的MAC地址或者是广播地址。则上传到网络层，否则丢弃该帧。

图1 TCP/IP协议栈

HTTP是一个client终端（用户）和server端（站点）请求和应答的标准（TCP）。通过使用Web浏览器、网络爬虫或者其他的工具，client发起一个HTTP请求到server上指定port（默认port为80）。我们称这个client为用户代理程序（user agent）。

应答的server上存储着一些资源。比方HTML文件和图像。我们称这个应答server为源server（origin server）。

在用户代理和源server中间可能存在多个中间层，比方代理，网关，或者隧道（tunnel）。

虽然TCP/IP协议是互联网上最流行的应用，HTTP协议中。并没有规定必须使用它或它支持的层。

其实。HTTP能够在不论什么互联网协议上，或其它网络上实现。HTTP假定其下层协议提供可靠的传输。

因此，不论什么能够提供这样的保证的协议都能够被其使用。

因此也就是其在TCP/IP协议族使用TCP作为其传输层。

通常。由HTTPclient发起一个请求，创建一个到server指定port（默认是80port）的TCP连接。

HTTPserver则在那个port监听client的请求。一旦收到请求。server会向client返回一个状态，比方"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其他信息。

发出的请求信息包含下面几个

·1. 请求行

比如GET /images/logo.gif HTTP/1.1，表示从/images文件夹下请求logo.gif这个文件。

2. 请求头

比如Accept-Language: en

3. 空行

4. 其它消息体

请求行和标题必须以<CR><LF>作为结尾。空行内必须仅仅有<CR><LF>而无其它空格。在HTTP/1.1协议中，全部的请求头。除Host外，都是可选的。

HTTP/1.1协议*定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

1. OPTIONS：这种方法可使server传回该资源所支持的全部HTTP请求方法。

用'*'来取代资源名称，向Webserver发送OPTIONS请求。能够測试server功能是否正常运作。

2. HEAD：与GET方法一样，都是向server发出指定资源的请求。仅仅只是server将不传回资源的本文部份。它的优点在于，使用这种方法能够在不必传输所有内容的情况下。就能够获取当中“关于该资源的信息”（元信息或称元数据）。

3. GET：向指定的资源发出“显示”请求。使用GET方法应该仅仅用在读取数据。而不应当被用于产生“副作用”的操作中，比如在Web Application中。当中一个原因是GET可能会被网络蜘蛛等任意訪问。參见安全方法

4. POST：向指定资源提交数据。请求server进行处理（比如提交表单或者上传文件）。

数据被包括在请求本文中。这个请求可能会创建新的资源或改动现有资源，或二者皆有。

5. PUT：向指定资源位置上传其最新内容。

6. DELETE：请求server删除Request-URI所标识的资源。

7. TRACE：回显server收到的请求。主要用于測试或诊断。

8. CONNECT：HTTP/1.1协议中预留给可以将连接改为管道方式的代理server。通经常使用于SSL加密server的链接（经由非加密的HTTP代理server）。

方法名称是区分大写和小写的。

当某个请求所针对的资源不支持相应的请求方法的时候，server应当返回状态码405（Method Not Allowed），当server不认识或者不支持相应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTPserver至少应该实现GET和HEAD方法，其它方法都是可选的。

当然，全部的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的HTTPserver还可以扩展自己定义的方法。比如：

 PATCH（由RFC5789指定的方法）:用于将局部改动应用到资源。

眼下有两种方法来创建安全超文本协议连接：HTTPS URI方案和HTTP 1.1请求头（由RFC2817引入）。

因为浏览器对后者的差点儿没有不论什么支持，因此HTTPS URI方案仍是创建安全超文本协议连接的主要手段。安全超文本连接协议使用https://取代http://

安全方法

对于GET和HEAD方法而言。除了进行获取资源信息外，这些请求不应当再有其它意义。也就是说。这些方法应当被觉得是“安全的”。 client可能会使用其它“非安全”方法，比如POST，PUT及DELETE，应该以特殊的方式（一般是button而不是超链接）告知客户可能的后果（比如一个button控制的资金交易），或请求的操作可能是不安全的（比如某个文件将被上传或删除）。

可是。不能想当然地觉得server在处理某个GET请求时不会产生不论什么副作用。

其实，非常多动态资源会把这作为其特性。这里重要的差别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。

副作用

假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就行被视作“幂等”的。GET。HEAD，PUT和DELETE方法都有这种幂等属性。相同因为依据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等的。

假如某个由若干个请求做成的请求串行产生的结果在反复运行这个请求串行或者当中不论什么一个或多个请求后仍没有发生变化，则这个请求串行便是“幂等”的。可是，可能出现若干个请求做成的请求串行是“非幂等”的。即使这个请求串行中全部运行的请求方法都是幂等的。

比如，这个请求串行的结果依赖于某个会在下次运行这个串行的过程中被改动的变量。

超文本传输协议已经演化出了非常多版本号。它们中的大部分都是向下兼容的。在RFC2145中描写叙述了HTTP版本号号的使用方法。client在请求的開始告诉server它採用的协议版本号号。而后者则在响应中採用同样或者更早的协议版本号。

HTTP/0.9

已过时。

仅仅接受GET一种请求方法，没有在通讯中指定版本号号，且不支持请求头。

因为该版本号不支持POST方法，因此client无法向server传递太多信息。

HTTP/1.0

这是第一个在通讯中指定版本号号的HTTP协议版本号，至今仍被广泛採用，特别是在代理server中。

HTTP/1.1

当前版本号。持久连接被默认採用，并能非常好地配合代理server工作。还支持以管道方式在同一时候发送多个请求。以便减少线路负载，提高传输速度。

HTTP/1.1相较于HTTP/1.0协议的差别主要体如今：

·                   缓存处理

·                   带宽优化及网络连接的使用

·                   错误通知的管理

·                   消息在网络中的发送

·                   互联网地址的维护

·                   安全性及完整性

全部HTTP响应的第一行都是状态行，依次是当前HTTP版本。3位数字组成的状态代码，以及描写叙述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

·                   1xx消息——请求已被server接收。继续处理

·                   2xx成功——请求已成功被server接收、理解、并接受

·                   3xx重定向——须要兴许操作才干完毕这一请求

·                   4xx请求错误——请求含有词法错误或者无法被运行

·                   5xxserver错误——server在处理某个正确请求时错误发生

尽管RFC2616中已经推荐了描写叙述状态的短语，比如"200 OK"，"404 Not Found"，可是WEB开发人员仍然可以自行决定採用何种短语。用以显示本地化的状态描写叙述或者自己定义信息。

在HTTP 0.9和1.0使用非持续连接，在非持续连接下，每一个tcp仅仅连接一个web对象。连接在每一个请求-回应对后都会关闭。一个连接可被多个请求反复利用的保持连接机制被引入。

这样的连接持续化显著地降低了请求延迟，由于客户不用在首次请求后再次进行TCP交互确认创建连接。

如今在HTTP 1.1使用持续连接，不必为每一个web对象创建一个新的连接，一个连接能够传送多个对象。 HTTP1.1还进行了带宽优化，比如1.1引入了分块传输编码来同意流化传输持续连接上发送的内容。代替原先的buffer式传输。

HTTP管道同意客户在上一个回应被收到前发送多重请求从而进一步降低了延迟时间。

还有一项协议的改进是byte serving（字节服务）。同意server依据客户的请求只传输资源的一部分。

基本HTTP协议

以下是一个HTTPclient与server之间会话的样例，执行于www.google.com。port80

client请求：

（末尾有一个空行。第一行指定方法、资源路径、协议版本号；第二行是在1.1版里必带的一个header作用指定主机）

server应答：

（紧跟着一个空行，而且由HTML格式的文本组成了Google的主页）

AJAX应用实例

AJAX即“Asynchronous JavaScript and XML”（异步的JavaScript与XML技术），指的是一套综合了多项技术的浏览器端网页开发技术。传统的Web应用同意用户端填写表单（form）。当提交表单时就向Webserver发送一个请求。server接收并处理传来的表单，然后送回一个新的网页。但这个做法浪费了很多带宽，由于在前后两个页面中的大部分HTML码往往是同样的。由于每次应用的沟通都须要向server发送请求。应用的回应时间依赖于server的回应时间。这导致了用户界面的回应比本机应用慢得多。

与此不同。AJAX应用能够仅向server发送并取回必须的数据。并在client採用JavaScript处理来自server的回应。

由于在server和浏览器之间交换的数据大量降低,server回应更快了。同一时候。非常多的处理工作能够在发出请求的client机器上完毕，因此Webserver的负荷也降低了。AJAX不是指一种单一的技术，而是有机地利用了一系列相关的技术。

尽管其名称包括XML，但实际上数据格式能够由JSON取代，进一步降低数据量，形成所谓的AJAJ。

一句话，AJAX基于HTTP协议。

代码清单test.html:

<script src="jquery.js"></script> <!-- Javascript --> <script type="text/javascript"> $(document).ready(function (){     $("#btn392").click(function(){             var url = "http://www.pureexample.com/backend/ajax_crossdomain.aspx";               //var url = "http://127.0.0.1:5000";            //[{    "Manufacturer": "HUMMER",    "Sold": 120,    "Month": "2012-11"}]            var success = function(data){             var html = [];             data = $.parseJSON(data); /* parse JSON */             /* loop through array */             $.each(data, function(index, d){                            html.push("Manufacturer : ", d.Manufacturer, ", ",                           "Sold : ", d.Sold, ", ",                           "Month : ", d.Month, "<br>");             });             $("#div391").html(html.join('')).css("background-color", "orange");         };         $.ajax({           type: 'GET',              url: url,           data:{todo:"jsonp"},           dataType: "jsonp",           crossDomain: true,                    cache:false,           success: success,           error:function(jqXHR, textStatus, errorThrown){             alert(errorThrown);           }         });     }); }); </script> <!-- HTML --> <a name="#jsonp-ajax"></a> <div id="example-section39">        <div>Car sale report</div>     <div id="div391"></div>     <button id="btn392" type="button">Click </button> </div>

 

一般情况下双向抓包信息：

GET /backend/ajax_crossdomain.aspx?callback=jQuery111006746286363340914_1393568973731&todo=jsonp&_=1393568973732HTTP/1.1

Host: www.pureexample.com

Connection:keep-alive

Accept: */*

User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) UbuntuChromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36

Accept-Encoding:gzip,deflate,sdch   /* 回包压缩 */

Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

Cookie:__cfduid=da94308c9f886169fb62c872c48d44e7c1393554685481

HTTP/1.1 200 OK

Server:cloudflare-nginx

Date: Fri, 28 Feb2014 06:31:01 GMT

Content-Type:text/html; charset=utf-8

Transfer-Encoding:chunked

Connection:keep-alive

Cache-Control:private

Vary:Accept-Encoding

Set-Cookie:ASP.NET_SessionId=yofjwnenn0cs5ijxx1jrdq55; path=/; HttpOnly

X-AspNet-Version:2.0.50727

X-Powered-By:ASP.NET

X-Powered-By-Plesk:PleskWin

CF-RAY:103b11cb0d290378-LAX

Content-Encoding:gzip

78     /* chunck大小为0x78字节*/

........... /* 回包为压缩形式 */

,M-.4444003713.0363661.44.74.465..47676.P..V..%..........."%+.%.P__.%..dp~N

P........+...2204.54T..U.......

a

...t..t...

0

通过分析双向的数据包能够看出，若请求头的Accept-Enconding为gzip，则服务端的回包会以压缩数据的形式回传。

去掉压缩双向抓包信息：

GET /backend/ajax_crossdomain.aspx?callback=jQuery111007808388310950249_1393570158984&todo=jsonp&_=1393570158985HTTP/1.0

Host:www.pureexample.com

Connection:keep-alive

Accept: */*

User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) UbuntuChromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36

Via: 1.1mtnproxy                

Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

Cookie:__cfduid=da94308c9f886169fb62c872c48d44e7c1393554685481;ASP.NET_SessionId=yofjwnenn0cs5ijxx1jrdq55

HTTP/1.1 200 OK

Server:cloudflare-nginx

Date: Fri, 28 Feb2014 06:50:16 GMT

Content-Type:text/html; charset=utf-8

Connection: close

Cache-Control:private

X-AspNet-Version:2.0.50727

X-Powered-By:ASP.NET

X-Powered-By-Plesk:PleskWin

CF-RAY:103b2dfbb05c0378-LAX

jQuery111007808388310950249_1393570158984('[{    "Manufacturer":"HUMMER",    "Sold":120,    "Month":"2012-11"}]')

通过分析双向的数据包能够看出。若请求头无Accept-Enconding信息。则服务端的回包会以普通形式回传。假设HTTP请求头为HTTP/1.0则，回应信息无Content-Length或CHUNCK的信息字段。

 

HTTP协议的展示。须要4个主要的要素，包含一个规范即http协议本身以及三个实体。即资源文件、webserver，浏览器。http协议规范了client与server之间数据交互的格式；资源文件包含html，js，css。等展示文件。webserver用于存储资源文件，并响应浏览器的资源文件请求；浏览器从webserver上请求资源文件，并解析展示。

图2 组成元素

如图1所看到的，webserver接入于公网，ip地址为61.155.154.42， url为www.demo.com。 资源文件包含index.html，index.js，index.css，others位于server的虚拟根文件夹下，index.html索引文件index.js，index.css。

图3 资源文件

若用户在浏览器的地址栏中输入www.demo.com并回车键确认。则将触发下面流程：

·                   浏览器所在client主机通过DNS查询。获取www.demo.com所相应的ip地址，并作为client与该ip地址相应的服务端建立http连接

·                   浏览器向server发起http根请求，浏览器从本机取出根文件index.html并回应浏览器

·                   浏览器从根请求回应中解析index.html文件里所引入的资源文件列表index.js，index.css等文件

·                   浏览器再次分别向server发起index.js。index.css等文件请求

·                   浏览器获取全部文件之后，解析渲染出全部资源文件，提供ui接口给用户

   

         图4 资源获取流程

通过以上描写叙述，我们知道。http代理server即是一个http协议的中继。

其所完毕的任务是插入浏览器与server之间的通信，截获浏览器的http请求，并模拟浏览器向server发起http请求。并把server的http回应。转回应于浏览器。这个动作相应浏览器来说，是透明的，可是对于开发人员来说。能够在代理server上做手脚。改动双向的报文。能够通过两种方式来实现http代理，其一为应用程序代理，其二tcp代理。其特征分别为：

·                   应用层代理。浏览器与代理server，代理server与server两个通信组队之间，分别建立tcp连接，并进行tcp传输数据。

代理server与浏览器握手之后，截获浏览器发出的GET报文，获取HOST字段与server握手，并把GET报文进行处理之后，转发给server。等待server的回包，并转发给浏览器。整个流程能够在应用层完毕。

图5 应用层代理server

能够看出代理server对client上来的GET报文有改动：1）HTTP/1.1改动为HTTP/1.0, 这样改动有两个作用，server对HTTP/1.0请求的回应报文没有Content-Length, 或CHUNCK的标示，而这两个标示与应用程序数据的长度相关。假设採用HTTP/1.1的请求，则在改动server的回包之后（回包长度发生变化）。须要又一次改动Content-Length或CHUNCK两个属性的值，而这两个值的改动添加了开发的难度；其二，server对HTTP/1.0回应不会保持长连接，即图中server响应index.html之后，tcp连接关闭，这样对于代理软件来说，软件easy稳定。减少了开发难度。

·                   TCP层代理

Ø         TCP报文插入

在TCP层做报文注入，涉及到了改动报文双向sequence, ack-sequence值的问题。

原因在于seq值与ack值与实际报文长度相关，假设改动了报文长度，显然须要改动seq, ack值：

图6 TCP之SEQ与ACK

Ø         TCP层代理报文插入

如图7所看到的。代理须要维护两个状态机，收到服务端带fin报文的数据包之后，和服务端完毕结束握手。同一时候去除fin报文的fin标志，把改报文发给浏览器，同一时候完毕和浏览器的报文插入以及结束握手：

图7 TCP之SEQ与ACK

Ø        TCP层代理状态机

1.       Eth0收到http报文的结束帧（带fin） 

 

2.     代理去掉fin标志

3.      代理插入一段报文，并加上fin标志

4.      浏览器对原始的http结束报文回应fin

问题：看起来server到浏览器的fin报文。并没有被代理扔掉，故而浏览器收到了两帧fin报文。

本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5193644.html，如需转载请自行联系原作者