【传输协议】TCP、UDP以及HTTP

OSI参考模型（Open System Interconnect)，即开放式系统互联，标准定义了网络互联的七层框架：1.物理层（最底层）；2.数据链路层；3.网络层；4.运输层；5.会话层；6.表示层；7.应用层。
** 可以参考 博客 **

一、TCP/IP：

TCP/IP协议分层

• 应用层： 向用户提供一组常用的应用程序，比如：电子邮件、文件传输访问(使用FTP协议)、远程登陆(使用TELNET协议)等；应用层有：FTP、HTTP、TELNET、SMTP、DNS等协议。

• 传输层： 提供应用程序间的通信，功能包括：1.格式化信息流；2.提供可靠传输；为实现可靠传输，规定接收端必须发回确认；传输层有：TCP协议与UDP协议；

• 网络层： 负责相邻计算机之间的通信，网络层有：IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议；

  • 处理来之传输层的分组发送请求，收到请求后，将分组装入IP数据报，填充报头，选择去往信宿机的路径，然后将数据报发往适当的网络接口；
  • 处理输入数据报：首先检查其合法性，然后进行寻径–假如该数据报已经到达信宿机，则去掉报头，将剩下的部分交给适当的传输协议；假如该数据报尚未到达信宿，则转发该数据报；
  • 处理路径、流控、拥塞问题；

IP是无连接的：
IP是用于计算机之间的通信，IP是无连接的通信协议，不会占用两个正在通信的计算机之间的通信线路，这样就降低了对网络线路的需求，每条线可以同时满足许多不同的计算机之间的通信需要；

通过IP，消息（或者其他数据）被分割为小的独立包，并通过因特网在计算机之间传送；

IP负责将每个包路由至目的地。

TCP使用固定的连接
TCP用于应用程序之间的通信，建立通信时，会发送一个请求，该请求被送到一个确切的地址。在双方通过三次“握手”之后，TCP将在两个应用程序之间建立一个全双工的通信，占用两个计算机之间的通信线路，直到它被一方或者双方关闭。

IP路由器
当一个IP包从一台机计算机被发送，它会到达一个IP路由器，直接或者通过其他路由器，IP路由器负责把这个包路由到目的地。
在一个相同的通信中，一个包所经由的路径可能会和其他的包不同，而路由器负责根据通信量、网络中的错误或者其他的参数来进行正确地寻址。

域名
在全世界，数量庞大的DNS服务器被连入因特网，DNS服务器负责将域名翻译为TCP/IP地址，同时负责使用新的域名信息更新彼此的系统。

TCP/IP
TCP负责应用软件和网络软件之间的通信；IP负责计算机之间的通信。
TCP负责将数据分割并装入IP包，然后在他们到达的时候，重新组合他们。
IP负责将包发送至接受者。

二、TCP：

TCP报文格式

• 16位源端口号： 16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。

• 16位目的端口号： 16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。

• 32位序号： 32位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN出现，序列码实际上是初始序列码（Initial Sequence Number，ISN），而第一个数据字节是ISN+1。这个序列号（序列码）可用来补偿传输中的不一致。

• 32位确认序号： 32位的序列号由接收端计算机使用，重组分段的报文成最初形式。如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。

• 4位首部长度： 4位包括TCP头大小，指示何处数据开始。

• 保留（6位）： 6位值域，这些位必须是0。为了将来定义新的用途而保留。

• 标志： 6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN:

  • URG： 紧急标志，紧急标志为1，表明该位有效；

  • ACK： 确认标志。表明确认序号栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号（w+1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

  • PSH： 推标志。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。在处理Telnet或rlogin等交互模式的连接时，该标志总是置位的。

  • RST： 复位标志。用于复位相应的TCP连接。

  • SYN： 同步标志。表明同步序列编号栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端（一般是客户端）的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

  • FIN： 结束标志。

• 16位窗口大小： 用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16字节字段，因而窗口大小最大为65535字节。

• 16位校验和： 16位TCP头。源机器基于数据内容计算一个数值，收信息机要与源机器数值 结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证的。

• 16位紧急指针： 指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。

• 选项： 长度不定，但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。

• 数据： 该TCP协议包负载的数据。

TCP三次握手

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

第一次握手： Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

第二次握手： Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

第三次握手： Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并且将确认序号（J+1）放在数据段，将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

TCP四次握手

所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

注：TIME_WAIT状态需要经过2MSL（最长报文寿命）才能返回到CLOSE状态

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。

TCP相关：

• SYN攻击：
  在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产生时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

#netstat -nap | grep SYN_RECV

• 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
  这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

• 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
  原因有二：

  • 保证TCP协议的全双工连接能够可靠关闭:
    如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
  • 保证这次连接的重复数据段从网络中消失:
    如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

三、UDP协议：

UDP（User Datagram Protocol），用户数据报协议，是OSI(Open System Interconnection，开放式系统互联) 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP提供了无连接通信，且不对传送数据包进行可靠性保证，适合于一次传输少量数据，UDP传输的可靠性由应用层负责。常用的UDP端口号有:
DNC-----端口号：53
TFTP-----端口号：69
SNMP-----端口号：161

UDP报文没有可靠性保证、顺序保证和流量控制字段等，可靠性较差。但是正因为UDP协议的控制选项较少，在数据传输过程中延迟小、数据传输效率高，适合对可靠性要求不高的应用程序，或者可以保障可靠性的应用程序，如DNS、TFTP、SNMP等。UDP在IP包中的位置如下：

可以看到，UDP其实就是在IP报文中添加了端口信息，使数据到达主机后送达至相应端口的应用程序。

UDP使用：

由于UDP的特性:它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们聊天用的QQ就是使用的UDP协议。

既然UDP是一种不可靠的网络协议，那么还有什么使用价值或必要呢?其实不然，在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。

UDP报头

UDP报头由4个域组成，其中每个域占用2个字节，如下：

• UDP协议使用端口号为不同的应用保留其各自的数据传输通道。 UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据包通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。
• 数据报的长度是指包括报头和数据部分在内的总字节数。 因为报头的长度是固定的，所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。
• UDP协议使用报头中的校验值来保证数据的安全。 校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。
• 许多链路层协议都提供错误检查，包括流行的以太网协议，也许你想知道为什么UDP也要提供检查和校验。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。 虽然UDP提供有错误检测，但检测到错误时，UDP不做错误校正，只是简单地把损坏的消息段扔掉，或者给应用程序提供警告信息。

UDP特性

• UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当UDP它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制;在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

• 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

• UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

• 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

• UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表(这里面有许多参数)。

• UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

UDP一次发送多少bytes好？

首先，我们知道TCP/IP通常被认为是一个四层协议系统，包括链路层、网络层、传输层、应用层。UDP属于传输层,下面我们由下至上一步一步来看: 以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的。 这个1500字节被称为链路层的MTU(最大传输单元)。 但这并不是指链路层的长度被限制在1500字节，其实这个MTU指的是链路层的数据区并不包括链路层的首部和尾部的18个字节。所以事实上这个1500字节就是网络层IP数据报的长度限制。因为IP数据报的首部为20字节，所以IP数据报的数据区长度最大为1480字节。而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的。又因为UDP数据报的首部8字节，所以UDP数据报的数据区最大长度为1472字节。这个1472字节就是我们可以使用的字节数。

当我们发送的UDP数据大于1472的时候会怎样呢？ 这也就是说IP数据报大于1500字节，大于MTU。这个时候发送方IP层就需要分片(fragmentation)。 把数据报分成若干片，使每一片都小于MTU。而接收方IP层则需要进行数据报的重组。这样就会多做许多事情，而更严重的是，由于UDP的特性，当某一片数据传送中丢失时，无法重组数据报，将导致丢弃整个UDP数据报。因此，在普通的局域网环境下，建议将UDP的数据控制在1472字节以下为好。

进行Internet编程时则不同,因为Internet上的路由器可能会将MTU设为不同的值. 如果我们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机制来调整MTU值,使数据报能够顺利到达目的地,这样就会做许多不必要的操作. 鉴于Internet上的标准MTU值为576字节, 所以我建议在进行Internet的UDP编程时. 最好将UDP的数据长度控件在548字节(576-8-20)以内。

UDP协议：低开销通信

UDP是一种简单协议，提供了基本的传输层功能。与TCP相比，UDP的开销极低，因为UDP是无连接的，并且不提供复杂的重新传输、排序和流量控制机制。

UDP数据报重组

与TCP的通信机制不同，由于UDP是无连接协议，因此通信发生之前不会建立会话。UDP是基于事务的，换言之，应用程序要发送数据时，它仅是发送数据而已。很多使用UDP的应用程序发送的数据量很小，用一个数据段就够了。但是也有一些应用程序需要发送大量数据，因此需要用多个数据段。UDP PDU(协议数据单元) 实际意义是数据报，尽管数据段和数据报可以互换使用来描述某个传输层PDU。

将多个数据报发送到目的主机时，它们可能使用了不同的路径，到达顺序也可能跟发送时的顺序不同。与TCP不同，UDP不跟踪序列号。UDP不会对数据报重组，因此也不会将数据恢复到传输时的顺序。

因此，UDP仅仅是将接收到的数据按照先来后到的顺序转发到应用程序。如果数据的顺序对应用程序很重要，那么应用程序只能自己标志数据的正确顺序，并决定如何处理这些数据。

UDP服务器进程与请求

与基于TCP的应用程序相同的是，基于UDP的服务器应用程序也被分配了公认端口或已注册的端口。当上述应用程序或进程运行时，它们就会接受与所分配端口相匹配的数据。当UDP收到用于某个端口的数据报时，它就会按照应用程序的端口号将数据发送到相应的应用程序。

UDP客户端进程

对于TCP而言，客户端/服务器模式的通信初始化采用由客户端应用程序向服务器进程请求数据的形式。而UDP客户端进程则是从动态可用端口中随机挑选一个端口号，用来作为会话的源端口。而目的端口通常都是分配到服务器进程的公认端口或已注册的端口。

采用随机的源端口号的另一个优点是提高安全性。如果目的端口的选择方式容易预测，那么网络入侵者很容易就可以通过尝试最可能开放的端口号访问客户端。

由于UDP不建立会话，因此一旦数据和端口号准备就绪，UDP就可以生成数据报并递交给网络层，并在网络上寻址和发送。

需要谨记的是，客户端选定了源端口和目的端口后，通信事务中的所有数据报文头都采用相同的端口对。对于从服务器到达客户端的数据来说，数据报头所含的源端口和目的端口作了互换。

四、HTTP

HTTP简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。

HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

主要特点

• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记；

• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间；

• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

• 支持B/S(Browser/Server)及C/S(Client/Server)模式。

HTTP之URL

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息。

URL,全称是UniformResourceLocator， 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.abcde.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：

• 协议部分：URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符；
• 域名部分：该URL的域名部分为“www.abcde.com”。一个URL中，也可以使用IP地址作为域名使用;
• 端口部分：跟在域名后面的是端口，域名和端口之间使用:作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口;
• 虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”;
• 文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名;
• 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
• 参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

URI和URL的区别

• URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源：
  Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个URI来定位的，URI一般由三部组成：
  ①访问资源的命名机制
  ②存放资源的主机名
  ③资源自身的名称，由路径表示，着重强调于资源。

• URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源
  URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
  采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
  ①协议(或称为服务方式)
  ②存有该资源的主机IP地址(有时也包括端口号)
  ③主机资源的具体地址。如目录和文件名等

• URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:java-net@java.sun.com

• URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

HTTP之请求消息Request

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

Get请求举例：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8

• 第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本:
  GET说明请求类型为GET，[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本；
• 第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息：
  从第二行起为请求头部，HOST将指出请求的目的地；User-Agent，服务器端和客户端脚本都能访问它，它是浏览器类型检测逻辑的重要基础，该信息由你的浏览器来定义，并且在每个请求中自动发送等等；
• 第三部分：空行，请求头部后面的空行是必须的
  即使第四部分的请求数据为空，也必须有空行；
• 第四部分：请求数据也叫主体，可以添加任意的其他数据（该例子请求数据为空）

HTTP之响应消息Response

一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息；
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

例子：

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>

• 第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成
  第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为(ok)；
• 第二部分：消息报头，用来说明客户端要使用的一些附加信息
  第二行和第三行为消息报头：
  Date: 生成响应的日期和时间；
  Content-Type: 指定了MIME类型的HTML(text/html),
  charset: 编码类型是UTF-8
• 第三部分：空行，消息报头后面的空行是必须的
• 第四部分：响应正文，服务器返回给客户端的文本信息。

HTTP之状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

• 1xx：指示信息----表示请求已接收，继续处理
• 2xx：成功----表示请求已被成功接收、理解、接受
• 3xx：重定向----要完成请求必须进行更进一步的操作
• 4xx：客户端错误----请求有语法错误或请求无法实现
• 5xx：服务器端错误----服务器未能实现合法的请求

HTTP请求方法

五种请求方法：OPTIONS, PUT, DELETE, TRACE和 CONNECT方法。

• GET 请求指定的页面信息，并返回实体主体。
• HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
• POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
• PUT 从客户端向服务器传送的数据取代指定的文档的内容。
• DELETE 请求服务器删除指定的页面。
• CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
• OPTIONS 允许客户端查看服务器的性能。
• TRACE 回显服务器收到的请求，主要用于测试或诊断。

HTTP工作原理

HTTP请求/响应步骤：

1. 客户端连接到Web服务器：
   一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接；

2. 发起HTTP请求：
   通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成；

3. 服务器接受请求并返回HTTP响应：
   Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4. 释放连接TCP连接：
   若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5. 客户端浏览器解析HTML内容：
   客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

GET和POST区别：

1. GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变，会把数据放在HTTP包的包体中；
2. 传输数据大小：
   GET：浏览器对URL长度有限制，所以对GET请求数据的大小也有限制；
   POST：由于不是通过URL传值，理论上数据不受 限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
3. 安全性：
   POST的安全性要比GET的安全性高；
4. GET，POST，SOAP
   get： 请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全；
   post： 请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form- urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输，但是它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。
   soap： 是http post的一个专用版本，遵循一种特殊的xml消息格式Content-type设置为: text/xml 任何数据都可以xml化。