参考: http://blog.csdn.net/baggio785/archive/2006/04/13/661410.aspx
模型: http://blog.csdn.net/baggio785/archive/2006/04/13/661412.aspx


HTTP请求模型

一、连接至Web服务器
一个客户端应用（如Web浏览器）打开到Web服务器的HTTP端口的一个套接字（缺省为80）。

例如：http://www.myweb.com:8080/index.html
在Java中，这将等同于代码：
Soceet socket=new Socket(“www.myweb.com”,8080);
InputStream in=socket.getInputStream();
OutputStream out=socket.getOutputStream();

二、发送HTTP请求
通过连接，客户端写一个ASCII文本请求行，后跟0或多个HTTP头标，一个空行和实现请求的任意数据。
一个请求由四个部分组成：请求行、请求头标、空行和请求数据
1.请求行：请求行由三个标记组成：请求方法、请求URI和HTTP版本，它们用空格分隔。
例如：GET /index.html HTTP/1.1
HTTP规范定义了8种可能的请求方法：
GET            检索URI中标识资源的一个简单请求
HEAD            与GET方法相同，服务器只返回状态行和头标，并不返回请求文档
POST            服务器接受被写入客户端输出流中的数据的请求
PUT            服务器保存请求数据作为指定URI新内容的请求
DELETE            服务器删除URI中命名的资源的请求
OPTIONS        关于服务器支持的请求方法信息的请求
TRACE            Web服务器反馈Http请求和其头标的请求
CONNECT        已文档化但当前未实现的一个方法，预留做隧道处理
2.请求头标：由关键字/值对组成，每行一对，关键字和值用冒号（:）分隔。
请求头标通知服务器有关于客户端的功能和标识，典型的请求头标有：
User-Agent        客户端厂家和版本
Accept            客户端可识别的内容类型列表
Content-Length    附加到请求的数据字节数
3.空行：最后一个请求头标之后是一个空行，发送回车符和退行，通知服务器以下不再有头标。
4.请求数据：使用POST传送数据，最常使用的是Content-Type和Content-Length头标。

三、服务端接受请求并返回HTTP响应
Web服务器解析请求，定位指定资源。服务器将资源副本写至套接字，在此处由客户端读取。
一个响应由四个部分组成；状态行、响应头标、空行、响应数据
1.状态行：状态行由三个标记组成：HTTP版本、响应代码和响应描述。
HTTP版本：向客户端指明其可理解的最高版本。
响应代码：3位的数字代码，指出请求的成功或失败，如果失败则指出原因。
响应描述：为响应代码的可读性解释。
例如：HTTP/1.1 200 OK
HTTP响应码：
1xx：信息，请求收到，继续处理
2xx：成功，行为被成功地接受、理解和采纳
3xx：重定向，为了完成请求，必须进一步执行的动作
4xx：客户端错误：
2.响应头标：像请求头标一样，它们指出服务器的功能，标识出响应数据的细节。
3.空行：最后一个响应头标之后是一个空行，发送回车符和退行，表明服务器以下不再有头标。
4.响应数据：HTML文档和图像等，也就是HTML本身。

四、服务器关闭连接，浏览器解析响应
1.浏览器首先解析状态行，查看表明请求是否成功的状态代码。
2.然后解析每一个响应头标，头标告知以下为若干字节的HTML。
3.读取响应数据HTML，根据HTML的语法和语义对其进行格式化，并在浏览器窗口中显示它。
4.一个HTML文档可能包含其它需要被载入的资源引用，浏览器识别这些引用，对其它的资源再进行额外的请求，此过程循环多次。

五、无状态连接
HTTP模型是无状态的，表明在处理一个请求时，Web服务器并不记住来自同一客户端的请求。

六、实例
1.浏览器发出请求
GET /index.html HTTP/1.1
服务器返回响应
HTTP /1.1 200 OK
Date: Apr 11 2006 15:32:08 GMT
Server: Apache/2.0.46(win32)
Content-Length: 119
Content-Type: text/html










2.浏览器发出请求
GET /index.css HTTP/1.1
服务器返回响应
HTTP /1.1 200 OK
Date: Apr 11 2006 15:32:08 GMT
Server: Apache/2.0.46(win32)
Connection: Keep-alive, close
Content-Length: 70
Content-Type: text/plane

h3{
font-size:20px;
font-weight:bold;
color:#005A9C;
}

3.浏览器发出请求
GET image/logo.png HTTP/1.1
服务器返回响应
HTTP /1.1 200 OK
Date: Apr 11 2006 15:32:08 GMT
Server: Apache/2.0.46(win32)
Connection: Keep-alive, close
Content-Length: 1280
Content-Type: text/plane

{Binary image data follows}

（附录）
1.HTTP规范：Internet工程制定组织（IETF）发布的RFC指定Internet标准，这些RFC被Internet研究发展机构广泛接受。因为它们是标准文档，故一般用正规语言编写，如立法文标一样。
2.RFC：RFC一旦被提出，就被编号且不会再改变，当一个标准被修改时，则给出一个新的RFC。作为标准，RFC在Internet上被广泛采用。
3.HTTP的几个重要RFC：
RFC1945    HTTP 1.0 描述
RFC2068    HTTP 1.1 初步描述
RFC2616    HTTP 1.1 标准
4.资源标识符URI（Uniform Resource Identifter，URI）


HTTP参考

一、HTTP码应码
响应码由三位十进制数字组成，它们出现在由HTTP服务器发送的响应的第一行。

响应码分五种类型，由它们的第一位数字表示：
1.1xx：信息，请求收到，继续处理
2.2xx：成功，行为被成功地接受、理解和采纳
3.3xx：重定向，为了完成请求，必须进一步执行的动作
4.4xx：客户端错误，请求包含语法错误或者请求无法实现
5.5xx：服务器错误，服务器不能实现一种明显无效的请求

下表显示每个响应码及其含义：
100            继续
101            分组交换协
200            OK
201            被创建
202            被采纳
203            非授权信息
204            无内容
205            重置内容
206            部分内容
300            多选项
301            永久地传送
302            找到
303            参见其他
304            未改动
305            使用代理
307            暂时重定向
400            错误请求
401            未授权
402            要求付费
403            禁止
404            未找到
405            不允许的方法
406            不被采纳
407            要求代理授权
408            请求超时
409            冲突
410            过期的
411            要求的长度
412            前提不成立
413            请求实例太大
414            请求URI太大
415            不支持的媒体类型
416            无法满足的请求范围
417            失败的预期
500            内部服务器错误
501            未被使用
502            网关错误
503            不可用的服务
504            网关超时
505            HTTP版本未被支持

二、HTTP头标
头标由主键/值对组成。它们描述客户端或者服务器的属性、被传输的资源以及应该实现连接。

四种不同类型的头标：
1.通用头标：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。
2.请求头标：允许客户端传递关于自身的信息和希望的响应形式。
3.响应头标：服务器和于传递自身信息的响应。
4.实体头标：定义被传送资源的信息。即可用于请求，也可用于响应。

头标格式：:

下表描述在HTTP/1.1中用到的头标
Accept 定义客户端可以处理的媒体类型，按优先级排序；
在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept: image/jpeg,image/png,*/*
Accept-Charset        定义客户端可以处理的字符集，按优先级排序；
在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding        定义客户端可以理解的编码机制。例如：Accept-Encoding:gzip,compress
Accept-Language    定义客户端乐于接受的自然语言列表。例如：Accept-Language: en,de
Accept-Ranges        一个响应头标，它允许服务器指明：将在给定的偏移和长度处，为资源组成部分的接受请求。
该头标的值被理解为请求范围的度量单位。例如Accept-Ranges: bytes或Accept-Ranges: none
Age 允许服务器规定自服务器生成该响应以来所经过的时间长度，以秒为单位。
该头标主要用于缓存响应。例如：Age: 30
Allow 一个响应头标，它定义一个由位于请求URI中的次源所支持的HTTP方法列表。例如：Allow: GET,PUT
aUTHORIZATION 一个响应头标，用于定义访问一种资源所必需的授权（域和被编码的用户ID与口令）。
例如：Authorization: Basic YXV0aG9yOnBoaWw=
Cache-Control 一个用于定义缓存指令的通用头标。例如：Cache-Control: max-age=30
Connection 一个用于表明是否保存socket连接为开放的通用头标。例如：Connection: close或Connection: keep-alive
Content-Base 一种定义基本URI的实体头标，为了在实体范围内解析相对URLs。
如果没有定义Content-Base头标解析相对URLs，使用Content-Location URI（存在且绝对）或使用URI请求。
例如：Content-Base: Http://www.myweb.com
Content-Encoding 一种介质类型修饰符，标明一个实体是如何编码的。例如：Content-Encoding: zip
Content-Language 用于指定在输入流中数据的自然语言类型。例如：Content-Language: en
Content-Length        指定包含于请求或响应中数据的字节长度。例如：Content-Length:382
Content-Location        指定包含于请求或响应中的资源定位（URI）。
如果是一绝。对URL它也作为被解析实体的相对URL的出发点。
例如：Content-Location: http://www.myweb.com/news
Content-MD5        实体的一种MD5摘要，用作校验和。
发送方和接受方都计算MD5摘要，接受方将其计算的值与此头标中传递的值进行比较。
例如：Content-MD5:
Content-Range        随部分实体一同发送；标明被插入字节的低位与高位字节偏移，也标明此实体的总长度。
例如：Content-Range: 1001-2000/5000
Contern-Type        标明发送或者接收的实体的MIME类型。例如：Content-Type: text/html
Date            发送HTTP消息的日期。例如：Date: Mon,10PR 18:42:51 GMT
ETag            一种实体头标，它向被发送的资源分派一个唯一的标识符。
对于可以使用多种URL请求的资源，ETag可以用于确定实际被发送的资源是否为同一资源。
例如：ETag: ”208f-419e-30f8dc99″
Expires            指定实体的有效期。例如：Expires: Mon,05 Dec 2008 12:00:00 GMT
Form            一种请求头标，给定控制用户代理的人工用户的电子邮件地址。例如：From: webmaster@myweb.com
Host            被请求资源的主机名。对于使用HTTP/1.1的请求而言，此域是强制性的。例如：Host: www.myweb.com
If-Modified-Since        如果包含了GET请求，导致该请求条件性地依赖于资源上次修改日期。
如果出现了此头标，并且自指定日期以来，此资源已被修改，应该反回一个304响应代码。
例如：If-Modified-Since: Mon,10PR 18:42:51 GMT
If-Match            如果包含于一个请求，指定一个或者多个实体标记。只发送其ETag与列表中标记区配的资源。
例如：If-Match: ”208f-419e-308dc99″
If-None-Match        如果包含一个请求，指定一个或者多个实体标记。资源的ETag不与列表中的任何一个条件匹配，操作才执行。
例如：If-None-Match: ”208f-419e-308dc99″
If-Range            指定资源的一个实体标记，客户端已经拥有此资源的一个拷贝。必须与Range头标一同使用。
如果此实体自上次被客户端检索以来，还不曾修改过，那么服务器只发送指定的范围，否则它将发送整个资源。
例如：Range: byte=0-499If-Range:”208f-419e-30f8dc99″
If-Unmodified-Since    只有自指定的日期以来，被请求的实体还不曾被修改过，才会返回此实体。
例如：If-Unmodified-Since:Mon,10PR 18:42:51 GMT
Last-Modified        指定被请求资源上次被修改的日期和时间。例如：Last-Modified: Mon,10PR 18:42:51 GMT
Location            对于一个已经移动的资源，用于重定向请求者至另一个位置。
与状态编码302（暂时移动）或者301（永久性移动）配合使用。
例如：Location: http://www2.myweb.com/index.jsp
Max-Forwards        一个用于TRACE方法的请求头标，以指定代理或网关的最大数目，该请求通过网关才得以路由。
在通过请求传递之前，代理或网关应该减少此数目。例如：Max-Forwards: 3
Pragma            一个通用头标，它发送实现相关的信息。例如：Pragma: no-cache
Proxy-Authenticate    类似于WWW-Authenticate，便是有意请求只来自请求链（代理）的下一个服务器的认证。
例如：Proxy-Authenticate: Basic realm-admin
Proxy-Proxy-Authorization    类似于授权，但并非有意传递任何比在即时服务器链中更进一步的内容。
例如：Proxy-Proxy-Authorization: Basic YXV0aG9yOnBoaWw=
Public            列表显示服务器所支持的方法集。例如：Public: OPTIONS,MGET,MHEAD,GET,HEAD
Range            指定一种度量单位和一个部分被请求资源的偏移范围。例如：Range: bytes=206-5513
Refener            一种请求头标域，标明产生请求的初始资源。对于HTML表单，它包含此表单的Web页面的地址。
例如：Refener: http://www.myweb.com/news/search.html
Retry-After        一种响应头标域，由服务器与状态编码503（无法提供服务）配合发送，以标明再次请求之前应该等待多长时间。
此时间即可以是一种日期，也可以是一种秒单位。例如：Retry-After: 18
Server            一种标明Web服务器软件及其版本号的头标。例如：Server: Apache/2.0.46(Win32)
Transfer-Encoding    一种通用头标，标明对应被接受方反向的消息体实施变换的类型。例如：Transfer-Encoding: chunked
Upgrade        允许服务器指定一种新的协议或者新的协议版本，与响应编码101（切换协议）配合使用。
例如：Upgrade: HTTP/2.0
User-Agent        定义用于产生请求的软件类型（典型的如Web浏览器）。
例如：User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT; DigExt)
Vary            一个响应头标，用于表示使用服务器驱动的协商从可用的响应表示中选择响应实体。例如：Vary: *
Via            一个包含所有中间主机和协议的通用头标，用于满足请求。例如：Via: 1.0 fred.com, 1.1 wilma.com
Warning            用于提供关于响应状态补充信息的响应头标。例如：Warning: 99 www.myweb.com Piano needs tuning
www-Authenticate    一个提示用户代理提供用户名和口令的响应头标，与状态编码401（未授权）配合使用。响应一个授权头标。
例如：www-Authenticate: Basic realm=zxm.mgmt

    UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。
    UDP数据报封装成一份IP数据报的格式如图11 - 1所示。



    RFC 768 [Postel 1980] 是UDP的正式规范。
    UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。由于缺乏可靠性，我们似乎觉得要避免使用UDP而使用一种可靠协议如TCP。我们在第1 7章讨论完TCP后将再回到这个话题，看看什么样的应用程序可以使用UDP。
    应用程序必须关心IP数据报的长度。如果它超过网络的M T U（2 . 8节），那么就要对IP数据报进行分片。如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做（我们在2 . 9节中已定义了路径M T U的概念）。在11 . 5节中，我们将讨论IP分片机制。
    UDP首部的各字段如图11 - 2所示。



    端口号表示发送进程和接收进程。在图1 - 8中，我们画出了TCP和UDP用目的端口号来分用来自IP层的数据的过程。由于IP层已经把IP数据报分配给TCP或UDP（根据IP首部中协议字段值），因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。TCP端口号与UDP端口号是相互独立的。
    尽管相互独立，如果TCP和UDP同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。
    UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节（发送一份0字节的UDP数据报是O K）。这个UDP长度是有冗余的。IP数据报长度指的是数据报全长（图3 - 1），因此UDP数据报长度是全长减去IP首部的长度（该值在首部长度字段中指定，如图3 - 1所示）。

TCP数据被封装在一个IP数据报中如下图：



显示TCP首部的数据格式。如果不计任选字段，它通常是20个字节。



    每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。

    有时，一个IP地址和一个端口号也称为一个插口（socket）。这个术语出现在最早的TCP规范（RFC793）校 罄此 沧魑 硎静 死 娴谋喑探涌凇２蹇诙裕╯ocketpair）(包含客户IP地址、客户端口号、服务器IP地址和服务器端口号的四元组)可唯一确定互联网络中每个TCP连接的双方。

    序号用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32bit的无符号数，序号到达232－1后又从0开始。

    当建立一个新的连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（InitialSequenceNumber）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标志消耗了一个序号（将在下章详细介绍如何建立和终止连接，届时我们将看到FIN标志也要占用一个序号）。

    既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加1。只有ACK标志（下面介绍）为1时确认序号字段才有效。

    发送ACK无需任何代价，因为32bit的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。

    TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。

    TCP可以表述为一个没有选择确认或否认的滑动窗口协议（滑动窗口协议用于数据传输将在20.3节介绍）。我们说TCP缺少选择确认是因为TCP首部中的确认序号表示发方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。例如，如果1～1024字节已经成功收到，下一报文段中包含序号从2049～3072的字节，收端并不能确认这个新的报文段。它所能做的就是发回一个确认序号为1025的ACK。它也无法对一个报文段进行否认。例如，如果收到包含1025～2048字节的报文段，但它的检验和错，TCP接收端所能做的就是发回一个确认序号为1025的ACK。

    首部长度给出首部中32bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4bit，因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节。在TCP首部中有6个标志比特。它们中的多个可同时被设置为1。我们在这儿简单介绍它们的用法。

    URG紧急指针（urgentpointer）有效

    ACK确认序号有效。

    PSH接收方应该尽快将这个报文段交给应用层。

    RST重建连接。

    SYN同步序号用来发起一个连接。这个标志和下一个标志将在第18章介绍。

    FIN发端完成发送任务。

    TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16bit字段，因而窗口大小最大为65535字节。在24.4节我们将看到新的窗口刻度选项，它允许这个值按比例变化以提供更大的窗口。

    检验和覆盖了整个的TCP报文段：TCP首部和TCP数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。TCP检验和的计算和UDP检验和的计算相似。

    只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。

    最常见的可选字段是最长报文大小，又称为MSS(MaximumSegmentSize)。每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。

    从上图中我们注意到TCP报文段中的数据部分是可选的。我们将在18章中看到在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段

IP数据报的格式如图3-1所示。普通的IP首部长为20个字节，除非含有选项字段。



4 个字节的32bit值以下面的次序传输：首先是0～7bit，其次8～15bit，然后16～23bit，最后是24~31bit。这种传输次序称作 bigendian字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序。以其他形式存储二进制整数 的机器，如littleendian格式，则必须在传输数据之前把首部转换成网络字节序。
目前的协议版本号是4，因此IP有时也称作IPv4。3.10节将对一种新版的IP协议进行讨论。
首部长度指的是首部占32bit字的数目，包括任何选项。由于它是一个4比特字段，因此首部最长为60个字节。在第8章中，我们将看到这种限制使某些选项如路由记录选项在当今已没有什么用处。普通IP数据报（没有任何选择项）字段的值是5。
服 务类型（TOS）字段包括一个3bit的优先权子字段（现在已被忽略），4bit的TOS子字段和1bit未用位但必须置0。4bit的TOS分别代表： 最小时延、最大吞吐量、最高可靠性和最小费用。4bit中只能置其中1bit。如果所有4bit均为0，那么就意味着是一般服务。RFC1340 [ReynoldsandPostel1992]描述了所有的标准应用如何设置这些服务类型。RFC1349[Almquist1992]对该RFC进行 了修正，更为详细地描述了TOS的特性。
列出了对不同应用建议的TOS值。在最后一列中给出的是十六进制值，因为这就是在后面将要看到的tcpdump命令输出。



Te l n e t 和R l o g i n这两个交互应用要求最小的传输时延，因为人们主要用它们来传输少量的交互数据。另一方面，F T P文件传输则要求有最大的吞吐量。最高可靠性被指明给网络管理（SN M P）和路由选择协议。用户网络新闻（Usenet news, NNTP）是唯一要求最小费用的应用。
现在大多数的T C P / I P实现都不支持TO S 特性，但是自4.3BSD Reno以后的新版系统都对它进行了设置。另外，新的路由协议如O S P F和I S - I S都能根据这些字段的值进行路由决策。
在2 . 1 0节中，我们提到S L I P一般提供基于服务类型的排队方法，允许对交互通信数据在处理大块数据之前进行处理。由于大多数的实现都不使用TO S 字段，因此这种排队机制由S L I P自己来判断和处理，驱动程序先查看协议字段（确定是否是一个T C P 段），然后检查T C P信源和信宿的端口号，以判断是否是一个交互服务。一个驱动程序的注释这样认为，这种“令人厌恶的处理方法”是必需的，因为大多数实现都不允许应用程序设 置TOS字段。
总长度字段是指整个I P数据报的长度，以字节为单位。利用首部长度字段和总长度字段，就可以知道I P数据报中数据内容的起始位置和长度。由于该字段长1 6比特，所以I P数据报最长可达6 5 5 3 5字节（回忆图2 - 5，超级通道的M T U为6 5 5 3 5 。它的意思其实不是一个真正的M T U—它使用了最长的I P数据报）。当数据报被分片时，该字段的值也随着变化。
尽管可以传送一个长达6 5 5 3 5字节的I P数据报，但是大多数的链路层都会对它进行分片。而且，主机也要求不能接收超过5 7 6字节的数据报。由于T C P把用户数据分成若干片，因此一般来说这个限制不会影响T C P。在后面的章节中将遇到大量使用U D P的应用（R I P，T F T P， B O O T P，D N S，以及S N M P），它们都限制用户数据报长度为5 1 2字节，小于5 7 6字节。但是，事实上现在大多数的实现（特别是那些支持网络文件系统N F S的实现）允许超过8 1 9 2字节的I P数据报。
总长度字段是I P首部中必要的内容，因为一些数据链路（如以太网）需要填充一些数据以达到最小长度。尽管以太网的最小帧长为4 6字节，但是I P数据可能会更短。如果没有总长度字段，那么I P层就不知道4 6字节中有多少是I P数据报的内容。
标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1
RFC791 [Postel 1981a]认为标识字段应该由让IP发送数据报的上层来选择。假设有两个连续的I P数据报，其中一个是由T C P生成的，而另一个是由U D P生成的，那么它们可能具有相同的标识字段。尽管这也可以照常工作（由重组算法来处理），但是在大多数从伯克利派生出来的系统中，每发送一个I P数据报，I P层都要把一个内核变量的值加1，不管交给IP的数据来自哪一层。内核变量的初始值根据系统引导时的时间来设置。
T T L（t i m e - t o - l i v e）生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。T T L的初始值由源主机设置（通常为3 2或6 4），一旦经过一个处理它的路由器，它的值就减去1。当该字段的值为0时，数据报就被丢弃，并发送I C M P报文通知源主机。第8 章我们讨论Tr a c e r o u t e 程序时将再回来讨论该字段。
首部检验和字段是根据I P首部计算的检验和码。它不对首部后面的数据进行计算。I C M P、I G M P、U D P和T C P在它们各自的首部中均含有同时覆盖首部和数据检验和码。
为了计算一份数据报的I P检验和，首先把检验和字段置为0。然后，对首部中每个16 bit 进行二进制反码求和（整个首部看成是由一串16 bit的字组成），结果存在检验和字段中。当收到一份I P数据报后，同样对首部中每个16 bit 进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和，因此，如果首部在传输过程中没有发生任何差错，那么接收方计算的结果应该 为全1。如果结果不是全1（即检验和错误），那么I P就丢弃收到的数据报。但是不生成差错报文，由上层去发现丢失的数据报并进行重传。
I C M P、I G M P、U D P和T C P都采用相同的检验和算法，尽管T C P和U D P除了本身的首部和数据外，在I P首部中还包含不同的字段。在RFC1071[Braden, Borman and Patridge 1988]中有关于如何计算I n t e r n e t检验和的实现技术。由于路由器经常只修改T TL字段（减1），因此当路由器转发一份报文时可以增加它的检验和，而不需要对I P 整个首部进行重新计算。R F C 1141Mallory and Kullberg 1990]为此给出了一个很有效的方法。
但是，标准的BSD实现在转发数据报时并不是采用这种增加的办法。每一份I P数据报都包含源I P地址和目的I P地址。我们在1 . 4节中说过，它们都是32 bit 的值。最后一个字段是任选项，是数据报中的一个可变长的可选信息。目前，这些任选项定义如下：
安全和处理限制（用于军事领域）

记录路径（让每个路由器都记下它的I P地址，）

时间戳（让每个路由器都记下它的I P地址和时间，）

宽松的源站选路（为数据报指定一系列必须经过的I P地址，）

严 格的源站选路（与宽松的源站选路类似，但是要求只能经过指定的这些地址，不能经过其他的地址）。这些选项很少被使用，并非所有的主机和路由器都支持这些选 项。选项字段一直都是以32 bit作为界限，在必要的时候插入值为0的填充字节。这样就保证I P首部始终是32 bit 的整数倍（这是首部长度字段所要求的）。

from：http://phpor.net/blog/read.php?416

im软件但凡要从web直接启动桌面客户端都是通过注册自己的协议来实现的，如果你已经安装了qq，你们 直接在浏览器的地址栏里输入：qq:// 就可以启动qq； 如果你安装了uc，那么直接在浏览器的地址栏里输入： uc:// 就可以直接启动uc了，当然处于安全考虑，可能会有提示的，因为你要从浏览器中跳出来去做其它浏览器无法控制的事情； 所以如果你在开始=>运行 里，输入： qq:// 或 uc:// 就不会提示，而是直接启动qq或uc了，这里也顺便给出了启动qq或uc的另类方法，如果你找不到qq或uc的快捷方式，或者找起来很麻烦，就可以这么搞了。下面还是赶快进入正题吧：

既然qq:// uc://都是一种协议，那么就可以按照http或https来修改了，开始=> 运行=> regedit

然后查找https 全字匹配，只查找“项”（这样会快而且精确），然后将https部分导出成reg文件，内容大致如下：



编辑reg文件:

去掉不需要的东西，把https替换成shagua（如果你愿意，可以随便起名字），把command部分替换成自己想要执行的应用程序，大致如下：



保存该文件，双击执行，傻瓜协议就注册完了，在浏览器的地址栏里输入：
shagua://
这时就可以启动你的应用程序了

就这么简单？这只是入门，还有更多，要学会自己研究哦:)