简单说说HTTP和TCP/IP协议

这篇文章简单说说HTTP和TCP协议
HTTP:应用层 TCP:传输层
(扩展 TCP/IP模型: 应用层:http https ftp ssh dns... 传输层:TCP UDP 网络层:IP ICMP IGMP 网络接口层: 以太网 令牌环..)

TPC/IP协议是传输层协议，主要解决数据如何在网络中传输， 而HTTP是应用层协议，主要解决如何包装数据。
关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。
WEB使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。”

• 先来说说TCP/IP协议

术语TCP/IP代表传输控制协议/网际协议，指的是一系列协议。
“IP”代表网际协议，TCP和UDP使用该协议从一个网络传送数据包到另一个网络。
TCP和UDP是FTP，HTTP和SMTP之类使用的传输层协议。虽然TCP和UDP都是用来传输其他协议的，
TCP和UDP都是用来传输其他协议的,但是他们的不同点就是 TCP提供着数据传输,和UDP没有,所以TCP有保证数据传输的机制

TCP和UDP的区别

1. TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上（实际上也很大程度上保证了）保证了连接的可靠性；而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。
2. 也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

简单说说TCP链接

TCP连接有三次握手
三次握手
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)

第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）

• 接下来说说HTTP协议

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之

HTTP协议是建立在TCP协议之上的一种应用。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

http请求:
请求方法 和 URI及使用的协议
请求方法:

GET     请求指定的页面信息，并返回实体主体。
HEAD     类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST     向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT     从客户端向服务器传送的数据取代指定的文档的内容。

DELETE      请求服务器删除指定的页面。
CONNECT     HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS     允许客户端查看服务器的性能。
TRACE     回显服务器收到的请求，主要用于测试或诊断。

请求正文
例如：
GET /Login/login.jsp HTTP/1.1
Accept:/ (-------Accept:浏览器可接受的MIME类型

            Accept-Charser:浏览器可以接受的字符集 
            Accept-Encoding:浏览器能够进行解码的数据编码方式。如gzip，通过返回gzip编码的HTML页面，多数情况可以减少5倍左右的下载时间 
            Refer:http://www.find908.com/Login/ 
            AcceptLanguage:zh-cn)

User-Agent:Mozilla/4.0 (compatible;MSIE 6.0;windows NT 5.1;SV1
Host:www.find908.com
Connection：Keep-Alive
Cookie: 】

a.通用首部：既可以出现在请求报文中，也可以出现在响应报文中。这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。不论报文是何种类型，都为其提供一些有用的信息。例如不管是构建请求报文还是响应报文，创建报文的日期时间都是同一个意思，因此提供这类信息的首部对这两种类型的报文来说都是通用的。下面用表格的形式给出通用的信息性首部。

通用的信息性首部：

首部 　　　　　　　描述
Connection 　　　允许客户端和服务器指定与请求/响应连接有关的选项
Date 　　　　　提供日期和时间标志，说明报文是什么时间创建的 MIME-Version 　给出了发送端使用的MIME版本
Trailer 　　　　　如果报文采用了分块传输编码(chunked transfer
encoding)方式，就可以用这个首部列出位于报文拖鞋 (trailer)部分的首部集合。
Transfer-Encoding 告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。
Update 　　　　　　给出了发送端可能想要"升级"使用的新版本或协议 Via 　　　　　　　　显示了报文经过的中间节点(代理、网关)

通用缓存首部：

首部 　　　　　　　　　　描述 Cache-Control 　　　　 用于随报文传送缓存指示
Pragma 　　　　　　　　 另一种随报文传送指示的方式，但并不专用于缓存

b.请求首部：提供更多有关请求的信息。请求首部是在请求报文中有意义的首部。用于说明是谁或什么在发送请求，请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部给出的客户端的信息，试着为客户端提供更好的响应。

首部 　　　　　　　　　　　　 描述
Client-IP 　　　　　　　　　　提供了运行客户端的机器的IP地址
From 　　　　　　　　　　　 提供了客户端用户的E-mail地址 Host 　　　　　　　　　　　
给出了接收请求的服务器的主机名和端口号 Referer 　　　　　　　　　　 提供了包含当前请求URI的文档的URL
UA-Color 　　　　　　　　　 提供了与客户端显示器的显示颜色有关的信息
UA-CPU 　　　　　　　　　　 给出了客户端CPU的类型或制造商
US-Disp 　　　　　　　　　　提供了与客户端显示器(屏幕)能力有关的信息 US-OS 　　　　　　　　　　
给出了客户端显示器的像素信息 UA-Pixels 　　　　　　　　　 提供了客户端显示器的像素信息
User-Agent 　　　　　　　　 将发起请求的应用程序名称告知服务器(User-Agent)用户代理

Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式，包括他们想要什么，可以使用什么，以及最重要的，他们不想要什么。这样服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到他们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。

首部 　　　　　　　　　　 描述
Accept 　　　　　　　　 告诉服务器能够发送哪些媒体类型
Accept-Charset 　　　　 告诉服务器能够发送哪些字符集
Accept-Encoding 　　　　 告诉服务器能够发送哪些编码方式
Accept-Language 　　　 告诉服务器能够发送哪些语言
TE 　　　　　　　　　　　 告诉服务器可以使用哪些扩展传输编码

条件请求首部：有时客户端希望为请求加上某些限制。比如客户端已经有了一份副本，就希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以加上这种限制，要求服务器在对请求进行相应之前，确保某个请求为真。

首部 　　　　　　　　　　 描述 Expect 　　　　　　　　 允许客户端列出某请求所要求的服务器行为
If-Match 　　　　　　　　如果实体标记与文档当前的实体标记相匹配，就或者这份文档
If-Modified-Since 　　　　除非在某个指定的日期之后资源被修改过，否则就限制这个请求
If-Range 　　　　　　　　允许对文档的某个范围进行条件请求 If-Unmodified-Since 　　
除非在某个指定的日期之后资源没有被修改过，否则就限制这个请求 Range 　　　　　　　　　如果服务器支持范围请求，就请求资源的指定范围

安全请求首部：HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。

首部 　　　　　　　　　　 描述
Authorization 　　　　　 包含了客户端提供给服务器，以便对其自身进行认证的数据
Cookie 　　　　　　　　客户端用它想服务器传送一个令牌-他并不是真正的安全首部，但却是隐含了安全功能
Cookie2 　　　　　　　　 用来说明请求端支持的cookie版本

代理请求首部：随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。

首部 　　　　　　　　　　 描述 Max-Forword 　　　　　
在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数-与TRACE方法一同使用
Proxy-Authorization 　　与Authorization首部相同，但这个首部是在与代理进行认证时使用的
Proxy-Connection 　　　与Connection首部相同，但这个首部是在于代理建立连接时使用的

c.响应首部：提供更多有关响应的信息。响应报文由自己的响应首部集。响应首部为客户端提供了一些额外的信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客　　　　　户端处理响应，并在将来发起更好的请求。

首部 　　　　　　　　 描述
Age 　　　　　　　　 (从最初创建开始)响应持续时间
Public 　　　　　　　
服务器为其资源支持的请求方法列表
Retry-After 　　　　 如果资源不可用的话，再次日期或时间重试
Server 　　　　　　　服务器应用程序软件的名称和版本
Title 　　　　　　　　 对HTML文档来说，就是HTML文档的源端给出的标题
Warning 　　　　　　 比原因短语中更详细的一些警告报文

协商首部：如果资源有多种表示方法-比如，如果服务器上有某文档的法语和德语译稿，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。

首部　　　　　　　　 描述
Accept-Ranges 　　 对此资源来说，服务器可接受的范围类型
Vary 　　　　　　　 服务器查看的其他首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表，服务器会根据这些首部的内容挑选出最合适的资源版本发送给客户端。

安全响应首部：
我们已经看到过安全请求首部了，本质上这里说的就是HTTP的质询/响应认证机制的响应侧。

首部 　　　　　　　　 描述

Proxy-Authenticate　来自代理的对客户端的质询列表
Set-Cookie　　　　不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识。
Set-Cookie2　　　　与Set-Cookie类似。 WWW-Authenticate 来自服务器的对客户端的质询列表

d、实体首部：描述主体的长度和内容，或者资源自身。有很多首部可以用来描述HTTP报文的负荷。由于请求和响应文本中都可能包含实体部分，所以在这两种类型的报文中都可能出现这些首部。实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体首部可以告知报文的接收者它在对什么进行处理。

首部 　　　　　　　描述
Allow 　　　　　　 列出了可以对此实体执行的请求方法
Location 　　　　告知客户端实体实际上位于何处；用于将接收端定向到资源的位置上去

内容首部：内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。比如，Web浏览器可以通过查看返回的内容类型，得知如何显示对象。

首部 　　　　　　　　　　　 描述
Content-Base 　　　　　　 解析主体中的相对URL时使用的基础URL
Content-Encoding 　　　　 对主体执行的任意编码方式
Content-Language 　　　　理解主体时最适宜使用的自然语言
Content-Length 　　　　　 主体的长度或尺寸
Content-Location 　　　　　资源实际所处的位置
Content-MD5 　　　　　　　主体的MD5校验
Content-Range 　　　　　　在整个资源中此实体表示的字节范围
Content-Type 　　　　　　 这个主体的对象模型

实体缓存首部：通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息，比如验证已缓存的资源副本是否仍然有效所需的信息，以及更好地估计已缓存资源合适失效所需的线索。

首部 　　　　　　 描述
ETag 　　　　　 与此实体有关的实体标记
Expires 　　　　 实体不在有效，要从原始的源端再次获取此实体的日期和时间 Last-Modified 　
这个实体最后一次被修改的日期和时间

从HTTP1.1之后默认使用了长连接，

在使用了长连接之后，服务器允许TCP连接的保持已减少握手过程，服务器也可以在客户端请求时或者请求超时时关闭这个连接，在某些情况下，服务器并不知道要发送的文档的长度，那么服务器就要把长度未知这个首部通知客户，并在发送数据后关闭这个连接，因此客户就可以知道数据结束的地方就要到了。另外在首部中可以通过定义Keep-Alive首部来定义TCP连接的最长使用限时。实际上头部有了Connection： Keep-alive这个首部并不代表服务器一定就会使用长连接，客户端和服务端都可以忽略这个首部的定义。

长连接模式下。当客户端向服务器发生请求之后，客户端如何判断服务器的数据已经发生完成？除了通过服务器关闭连接来被动的关闭HTTP的TCP连接之外，可以通过消息首部字段Content-Length来判断数据传输是否完毕，单位为字节

关于HTTP的安全：

HTTP本身并不提供安全，然而通过在传输层和应用层中使用安全套接层（SSL）可以使HTTP运行在安全的环境下，即HTTPS，HTTPS可以提供保密性，客户和服务器鉴别以及数据的完整性。

SSL的设计时为了给应用层生成的数据提供安全以及压缩服务，一般来说SSL能接收来自任何应用层协议的数据，但最多情况下这个应用层的协议就是HTTP，SSL对应用层传来的数据提供多种服务：

分片：SSL把数据划分为长度小于或者等于2的14次字节的数据分片

压缩：数据分片通过使用一种由客户端和服务器协商好的无损压缩方式进行压缩，这个服务是可选的。

报文完整性：为了保护数据的完整性，SSL使用密钥散列函数来创建MAC。

保密：为了提供保密性，原始的数据和MAC一起用对称密钥加密技术来加密。

组帧：先在被加密的有效载荷上添加一个首部，然后再把这个恶有效载荷传递给可靠的运输层协议。