HTTP协议之梗概

程序员必修课，今天我们一起来巩固网络知识吧。

了解web及网络基础

1. Web建立在什么技术之上？

总结:web 是建立在HTTP协议上通信的。
详解：

2. HTTP协议是如何诞生并发展的？

HTTP 的诞生是为了知识共享而规划Web。
最初设想的基本理念是：借助多文档之间相互关联行程的超文本（HyperText）,连成可相互参阅的WWW（World Wide Web，万维网）。
现在已经提出3项WWW构建技术，分别是：把SGML（Standard Generalized Markup Language，标准通用标记语言）作为页面的文本标记语言的HTML（HyperTextMarkupLanguage，超文本标记语言）；作为文档传递协议的HTTP；指定文档所在地址的URL（Uniform Resource Locator，统一资源定位符）。WWW这一名称，是Web浏览器当年用来浏览超文本的客户端应用程序时的名称。现在则用来表示这一系列的集合，也可以简称为web。
成长和现状：1997年1月公布的HTTP/1.1是目前主流的HTTP协议版本。当初的标准是RFC2068，之后发布的修订版RFC2616就是当前的主流版。
当年的HTTP协议的出现目的是为了解决文本传输的难题。由于协议本身非常简单，于是在此基础上设想了很多应用方法，并投入到实际使用中。现在HTTP协议已经超出Web框架的局限，被运用在各个场景中。

3.TCP/IP 协议族

TCP/IP 和HTTP的关系：通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的，HTTP只是属于它内部的一个子集。TCP/IP是互联网相关的各类协议族的总称。

4.TCP/IP 的分层管理

TCP/IP协议族层次：应用层、传输层、网络层、和数据链路层。把TCP/IP层次化的好处：每个层次内部设计可以自由改动。并且设计变得相对简单。

1.各层的作用：

应用层：决定用户提供应用服务时的通信活动。eg：FTP（File Transfer Protocol）文件传输协议和DNS（Domain Name System）域名系统以及HTTP协议。

传输层：对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。

网络层（有名网络互联层）：网络层用来处理在网络上流动的数据包。数据包是网络传输最小的数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层：（又名数据链路层，网络接口层）用来处理连接网络的硬件部分。包括控制操作系统，硬件的设备驱动，NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

2.TCP/IP通信传输流:

1.png

总结可以看出利用TCP/IP通过分层顺序进行网络通信时，发送端走向：从应用层往下走，接收端走向：从应用层往上走。
具体实现：

2.png

以HTTP传输举例：
1.作为发送端的客户端在 应用层（HTTP协议层）发出一个请求；
2.为了方便传输，在传输层（TCP协议）把应用层处收到的数据（HTTP协议请求报文）进行分割，并在各个报文上打上标记序号及口号后转发给网络层；
3.在网络层（IP层）增加作为通讯目的的MAC地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全。
4.接受端的服务在链路层接收到数据，按序往上层发送，一直到应用层，当传输到应用层，才能算真正接收到由客户端发送过来的HTTP协议请求。
发送端在层与层之间传输数据时，每经过一层时必定会被打上一个改层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时，会把对应的首部消去。
这种把数据信息包装起来的做法叫封装（encapsulate）。

3.与 HTTP 关系密切的协议 : IP、TCP 和DNS

1.负责传输的 IP 协议
“IP”其实是一种协议的名称,IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方 那里，则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定
地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换，但 MAC
地址基本上不会更改。使用 ARP 协议凭借 MAC 地址进行通信,ARP 是一种用以解析地址的协议，根据通信方的 IP 地址就可以反查出对应的 MAC 地址。由于存在路由选择（routing）机制没有人能够全面掌握互联网中的传输状况。原因是我们无法确定中转站转了几转。

2.确保可靠性的 TCP 协议

3.png

按层次分，TCP 位于传输层，提供可靠的字节流服务。（TCP三次握手工作方式中）如何传输才能确保数据能到达目标？具体操作过程是怎样的？

字节流服务（Byte Stream Service）是将大块数据分割成以报文段（segment）为单位的数据包进行管理传输的服务，这样做的目的是方便传输。TCP 协议为了更容易传送大数据才把数据分割，而且 TCP 协议能够 确认数据最终是否送达到对方。化整为零。为了准确无误地将数据送达目标处，TCP 协议采用了三次握手（three-way handshaking）策略。用 TCP 协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和ACK（acknowledgement）。发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后， 回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。最后，发 送端再回传一个带 ACK 标志的数据包，代表“握手”结束。若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发送相同的数据包。TCP 协议还有其他各种手段来保证通信的可靠性。

TODO有待补充##

1).TCP 协议还有哪些手段确保通信可靠？
重传策略：TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认（Acknowlegement）就关闭该重传，如果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中，TCP必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。这种重传策略的关键是对定时器初值的设定。
窗口确认：TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认，并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。TCP在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。
2).为何化整为零会让传输更方便。这是由哪些硬件或软件条件制约的？

3.负责域名解析的 DNS 服务
DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的 协议。它提供域名到 IP 地址之间的解析服务。计算机既可以被赋予 IP 地址，也可以被赋予主机名和域名。比如www.baidu.com。

DNS 服务位于应用层，可类比HTTP协议。它的产生是为了解决计算机和人类记忆习惯不同的转换问题的。DNS 协议提供通过域名查找 IP 地址，或逆向从 IP 地址反查域名的服务。

4.总结各种协议与 HTTP 协议的关系

4.png

5.URI 和 URL
与 URI（统一资源标识符）相比，我们更熟悉 URL（Uniform Resource Locator，统一资源定位符）。URL 正是使用 Web 浏览器等 访问 Web 页面时需要输入的网页地址。
URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联
网上所处的位置）。可见 URL 是 URI 的子集。
绝对 URI 的格式

5.png

HTTP简单了解

1.HTTP 协议用于客户端和服务器端之间的通信

通过请求和相应的交换达成通信，客户端发出请求，服务器段响应回复。
请求报文构成：

6.png

响应报文构成：

7.png

2.HTTP是不保存状态的协议

即协议对于发送过的请求或相应不做持久化处理。
好处：自然可减少服务器的 CPU 及内存资源的消耗。
坏处：让服务器管理全部客户端状态则会成为负担。
HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于
是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管
理状态了。

具体原理：
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的
首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器
发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出
去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一
个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前
的状态信息。

请求报文（没有 Cookie 信息的状态）

    GET /reader/ HTTP/1.1
    Host: hackr.jp
    *首部字段内没有Cookie的相关信息

响应报文（服务器端生成 Cookie 信息）

    
    HTTP/1.1 200 OK
    Date: Thu, 12 Jul 2012 07:12:20 GMT Server: Apache
    ＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
    10-Oct-12 07:12:20 GMT＞
    Content-Type: text/plain; charset=UTF-8

请求报文（自动发送保存着的 Cookie 信息）

    
    GET /image/ HTTP/1.1
    Host: hackr.jp
    Cookie: sid=1342077140226724

AF注入cookie时我们可以这么注入。需求：想让一个用户的登录状态一直都是登录的，直到其点击退出登录相应。可以直接对该用户的cookie进行持久化，然后每次请求的时候进行注入。

    manager.requestSerializer = [AFHTTPRequestSerializer serializer];
    NSString *sessionid = [[NSUserDefaults standardUserDefaults] objectForKey:@"sessionid"];
    NSString * sessionstr = [NSString stringWithFormat:@"JSESSIONID=%@; Path=/sdlxdbyxgs/; HttpOnly",sessionid];
    [manager.requestSerializer setValue:sessionstr forHTTPHeaderField:@"Cookie"];

3.请求URI定位资源

4.告知服务器意图的 HTTP 方法

下面，我们介绍 HTTP/1.1 中可使用的方法。
1.GET ：获取资源

2.POST：传输实体主体

3.PUT：传输文件

局限：但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若配合 Web 应用程序的验证机制，或架构设计采用RES（REpresentational State Transfer，表征状态转移）标准的同类
Web 网站，就可能会开放使用 PUT 方法。

4.HEAD：获得报文首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认
URI 的有效性及资源更新的日期时间等。

5.DELETE：删除文件

6.OPTIONS：询问支持的方法

7.TRACE：追踪路径

8.CONNECT：要求用隧道协议连接代理

CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。此处：GitHub个人证书配置的地方就有需要配置SSL证书的就是进行加密网络隧道传输的。

思考：
用HTTP中的协议直接put或者delete文件和我们发送post请求让服务器自己删除文件哪个效率更高呢？

在 HTTP/1.1 中，所有的连接默认都是持久连接。
好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高

管线化

管线化技术出现后，不用等待响应亦可直接发送下一个请求。
比如，当请求一个包含 10 张图片的 HTML Web 页面，与挨个连接相
比，用持久连接可以让请求更快结束。而管线化技术则比持久连接还
要快。请求数越多，时间差就越明显。

3.HTTP 报文内的 HTTP信息

用于 HTTP 协议交互的信息被称为 HTTP 报文。HTTP 报文大致可分为报文首部和报文主体两块。编码提升传输速率。

1.HTTP请求报文

GET / HTTP/1.1   #用的是那种请求遵守的什么协议
Host: hackr.jp  #请求资源所在的服务器
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Ge     #HTTP客户端程序的信息
Accept: text/html,application/xhtml+xml,application/xml;q=0         #用户代理可处理的媒体类型
Accept-Language: ja,en-us;q=0.7,en;q=0.3 #优先的语言
Accept-Encoding: gzip, deflate          #优先的内容编码
DNT: 1
Connection: keep-alive              #逐跳首部，链接管理
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT #比较资源的更新时间（与If-Modified-Since相 
If-None-Match: "45bae1-16a-46d776ac" #比较实体标记（与 If-Match 相反）
Cache-Control: max-age=0 #控制缓存的行为

2.响应报文

HTTP/1.1 304 Not Modified 
Date: Thu, 07 Jun 2012 07:21:36 GMT Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"

10.png

11.png

12.png

13.png

3.拓展非HTTP/1.1首字段

在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定 义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定义的首部字段，它们的使用频率也很高。

这些非正式的首部字段统一归纳在 RFC4229 HTTP Header Field
Registrations 中。

6.2.6　End-to-end 首部和 Hop-by-hop 首部

HTTP 首部字段将定义成缓存代理和非缓存代理的行为，分成 2 种类型。
端到端首部（End-to-end Header）

分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必
须保存在由缓存生成的响应中，另外规定它必须被转发。

逐跳首部（Hop-by-hop Header）

分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再 转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提 供 Connection 首部字段。
下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外，
其他所有字段都属于端到端首部。

14.png

4.确保 Web 安全的HTTPS

1.HTTP的缺点：

同其他未加密协议一样，HTTP 主要存在安全性上的不足。具体表现在：
1.通信使用明文（不加密），内容可能会被窃听
2.不验证通信方的身份，因此有可能遭遇伪装
3.无法证明报文的完整性，所以有可能已遭篡改

2.HTTPS = HTTP+ 加密 + 认证 + 完整性保护

HTTPS 是身披 SSL 外壳的 HTTP，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。

15.png

3.相互交换密钥的公开密钥加密技术

SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。

1）共享密钥加密

优点：解密中间环节少，处理速度快。
缺点：传输过程不安全。

2）公开密钥加密

缺点：相对共享密钥来说处理速度慢。
优点：解决了共享密钥密钥发送中被人使用的问题。
原理：
为了解决密钥发送问题，公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思
义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

16.png

3.HTTPS 采用混合加密机制

17.png

将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

4.证明公开密钥正确性的证书

场景：公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。

比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

措施：使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

4.HTTPS 的安全通信机制

HTTPS这么安全可靠，为何所有的 Web 网站不一直使用HTTPS ？
1.加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
2.节约购买证书的开销。证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。

5.确认访问用户身份的认证机制

HTTP 使用的认证方式：
HTTP/1.1 使用的认证方式如下所示。

BASIC 认证（基本认证）
DIGEST 认证（摘要认证）
SSL 客户端认证         （常用）
FormBase 认证（基于表单认证）
Windows 统一认证（Keberos 认证、NTLM 认证）

1.BASIC 认证（基本认证）

BASIC 认证（基本认证）是 Web 服务器与通信客户端之间进行的认证方式。
局限：1.BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。
2.想再进行一次 BASIC 认证时，一般的浏览器却无法实现认证注销操作。
3.步骤繁琐不灵活。

2.DIGEST 认证（challenge/response）

DIGEST 认证是质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返
回给对方进行认证的方式。
局限：1.DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。
2.步骤繁琐不灵活。

3.　SSL 客户端认证

从使用用户 ID 和密码的认证方式方面来讲，只要二者的内容正确， 即可认证是本人的行为。但如果用户 ID 和密码被盗，就很有可能被 第三者冒充。利用 SSL 客户端认证则可以避免该情况的发生。

SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。客户端证书需要支付一 定费用才能使用。费用是指，从认证机构购买客户端证书的费用，以及服务器运营者为保证自己搭建的认证机构安全运营所产生的费用。

SSL 客户端认证采用双因素认证
第一个认证因素的 SSL 客户端证书用来认证客户端计算机，
另一个认证因素的密码则用来确定这是用户本人的行为。

4.基于表单的认证

基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务 器上的 Web 应用程序发送登录信息（Credential），按登录信息的验 证结果认证。eg:登录界面。一般会使用 Cookie 来管理Session（会话）。

20.png

为了解决泄露风险可以先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。

参考文献：
1.《图解HTTP》