HTTP学习笔记

TCP/IP协议族按层次分别以下4层：应用层、传输层、网络层和数据链路层
应用层：应用层决定了向用户提供应用服务时通信的活动。TCP/IP协议族内预存了各类通用的应用服务，比如,FTP(File Transfer Protocol，文件传输协议)和 DNS(Domain Name System,域名系统)服务就是其中的两类，HTTP协议也处于该层
传输层：传输层对上层应用层提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP(Transmission Control Protocol,传输控制协议)和UDP(User Data Protocol,用户数据报协议)。
网络层(又称网络互连层)：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径(所谓的传输路线)到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层(又名数据链路层，网络接口层)：用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC(Network Interface Card,网络适配器，即网卡),及光纤等物理可见部分(还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内

1.3 TCP/IP通信传输流

HTTP学习笔记

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信，发送端从应用层往下走，接收端则往应用层往上走。
例如HTTP来说，首先作为发送端的客户端在应用层(HTTP协议)发出一个想看某个Web页面的HTTP请求，接着，为了传输方便，在传输层(TCP协议)把应用层处接收到的数据(HTTP请求报文)进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。在网络层(IP协议)，增加作为通信目的地的MAC地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全了。接收端的服务器在链路层收到数据，按顺序往上层发送，一直到应用层，当传输到应用层，才能算真正接收到由客户端发送过来的HTTP请求

HTTP学习笔记

发送层在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去
这种把数据信息包装起来的做法称为封装

1.4 负责传输的IP协议

IP协议的作用是把各种数据包发送给对方，而需要保证准确传送到对方那里，则需要满足各类条件。其中两个重要的条件是IP地址和MAC地址(Media Access Control Address)
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址，IP地址可以和MAC地址进行配对。IP地址可以变换，而MAC地址进本上不会更改
IP间的通信依赖MAC地址，在网络上，通信的双发在同一局域网(LAN)内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方，而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标，这时会采用ARP协议(Address Resolution Protocol)，ARP协议是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址

1.5 TCP协议

为了方便传输，TCP协议将大块数据分隔以报文段为单位的数据包进行管理
为了准确无误地将数据送达目标处，TCP协议采用了三次握手(three-way handshaking)策略。用TCP协议把数据包发送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达，握手过程中使用了TCP的标志(flag)—SYN(synchronize)和ACK(acknowledgement)

HTTP学习笔记

1.6 DNS服务

DNS服务是和HTTP协议一样位于应用层的协议，它提供域名到IP地址之间的解析服务，DNS协议提供通过域名查找IP地址或逆向从IP地址反查域名的服务

HTTP学习笔记

1.7 URI格式

绝对URI

HTTP学习笔记

相对URL 指从浏览器中基本URI处指定的URL，形如/image/logo.gif
URI 和 URL的区别

URL可以是URI 也可以不是URI 这要根据该URL是否是唯一的资源标示符
www.baidu.com是URL 不是URI
www.baidu.com/index.html 即是URL 也是URI
URL每部分都有具体含义 URI仅仅是唯一标识字符串

2. HTTP协议

2.1 通过请求和相应的交换达成通信

HTTP协议规定，请求从客户端发出，最后服务器响应该请求并返回，即服务器端在没有接收到请求之前不会发送响应
示例

HTTP学习笔记

起始开头的GET表示请求访问服务器的类型，成为方法。随后的字符串/index.html指明了请求访问的资源对象，也叫请求URI，最后的HTTP/1.1为HTTP的版本号，用来提示客户端使用的HTTP协议功能

接收到请求的服务器，会将请求内容的处理结果以响应的形式返回，例如：

HTTP学习笔记

2.2 HTTP方法

2.2.1 GET方法(获取资源)

GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容，也就是说，如果请求的资源的是文本，那就保持原样返回；如果是像CGI(Common Gateway Interface , 通用网关接口)那样的程序，则返回经过执行后的输出结果
示例：

HTTP学习笔记

2.2.2 POST方法(传输实体主体)

虽然GET方法也可以传输实体的主体，但是一般不用GET方法进行传输，而是用POST方法，主要原因为：

1.数据长度的限制: 当发送数据时，GET发送向URL添加数据，URL的长度是受限制的，而POST不受限制
2.数据类型的限制: GET方法只允许ASCII字符，而POST方法没有限制
3.安全性: 与POST相比，GET方法的安全性较差，因为其所发送的数据是URL的一部分，
         而POST方法参数不会保存在浏览器历史和web服务器日志中，更为安全
4.可见性: GET方法的数据在URL中对所有人都是可见的，POST方法的数据不会显示在URL中

示例

HTTP学习笔记

3. HTTP报文

3.1 请求报文及响应报文的结构

HTTP学习笔记

请求行，包含用于请求的方法、请求URI和HTTP版本
状态行，包含表明响应结果的状态码、原因短语和HTTP版本
首部字段，包含表示请求和响应的各种条件和属性的各类首部
- 一般有四个首部，分别是：通用首部、请求首部、响应首部、实体首部
其他，可能包含HTTP的RFC里未定义的首部(Cookie等)

3.2 报文主体和实体主体

报文，是HTTP通信中的基本单位，由8位组字节流(octet sequence，其中octet为8个比特)组成，通过HTTP通信传输
实体，作为请求或响应的有效载荷数据(补充项)被传输，其内容由实体首部和实体主体组成
HTTP报文的主体用于传输请求或响应的实体主体，通常情况下，报文主体等于实体主体，只有当传输中进行编码操作时，实体主体的内容发生变化才导致它和报文主体产生差异

3.3 多部分集合对象

HTTP协议中采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体，通常是在图片或文本文件上传时使用，多部分对象集合包含的对象有：

1. multipart/form-data   在 Web 表单文件上传时使用
2. multipart/byteranges 状态码 206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。

在HTTP报文中使用多部分对象集合时，需要在首部字段里加上Content-type

3.4 内容协商返回最合适的内容

同一个Web网站有可能存在着多份相同内容的页面，比如英文版和中文版的Web页面，他们内容上虽相同，但是使用的语言却不同，当浏览器的默认语言为英文或中文，访问相同URI的Web页面时，则会显示对应的英文版或中文版的Web页面，这样的机制称为内容协商
内容协商机制是指客户端和服务器端响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准，包含在请求报文中的某些首部字段就是判断的基准，这些首部字段有:

Accept   Accept-Charset  Accept-Encoding  Accept-Language  Content-Language

内容协商主要有一下三种类型
- 服务器驱动协商，由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不一定能筛选出最优内容
- 客户端驱动协商，由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用 JavaScript 脚本在 Web 页面上自动进行上述选择。比如按 OS 的类型或浏览器类型，自行切换成 PC 版页面或手机版页面。
- 透明协商，是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。

4.HTTP状态码

4.1 状态码的类别

HTTP学习笔记

只要遵守状态类别的定义，即时改变RFC2616中定义的状态，或服务器端自行创建状态码都没问题

4.2 2XX成功

200 OK ，表示从客户端发来的请求在服务器端被正常处理
204 No Content , 该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分，另外，也不允许返回任何实体的主体，比如，当从浏览器发出请求处理后，返回204响应，那么浏览器显示的页面不发胜更新。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送信息内容的情况下使用
206 Partial Content , 该状态码表示客户端进行了范围请求，而服务器成功执行了这部分Get请求，即客户端对服务器端资源某一部分的请求被服务器端成功执行

4.3 3XX重定向

301 Moved Permanently，永久性重定向。该状态码表示请求的资源已被分配新的URI，以后应使用资源现在所指的URI
302 Found，临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户(本次)能使用新的URI访问
303 See Other , 该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源

4.4 4XX客户端错误

400 Bad Request，该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。
401 Unauthorized，该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示用户认证失败。
403 Forbidden，该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了
404 Not Found，该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

5XX服务器错误

500 Internal Server Error，该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。
503 Service Unavailable ，该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

5.HTTP首部字段

5.1 首部字段结构

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分隔。例如：

Content-Type: text/html
Keep-Alive: timeout=15, max=100

5.2 首部字段类型

通用首部字段(General Header Fields),请求报文和响应报文两方都会使用的首部。
请求首部字段(Request Header Fields),从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段(Response Header Fields),从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段(Entity Header Fields),针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

6. HTTPS

6.1 通信的加密

HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTPSecure，超文本传输安全协议）或 HTTP over SSL。

6.2 HTTPS通信

HTTP学习笔记

HTTPS通信步骤：

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及**长度等）。
步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开**证书。
步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开**进行加密。
步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret **加密。
步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤 8： 服务器同样发送 Change Cipher Spec 报文。
步骤 9： 服务器同样发送 Finished 报文。
步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
步骤 11： 应用层协议通信，即发送 HTTP 响应。
步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

6.番外

6.1 HTTP长连接和短连接

短连接是指服务器端与客户端完成一次TCP的三次握手后就断开连接，每一次请求和响应的过程都是请求-连接-响应-断开，而长连接指的是HTTP连接后客户端与服务器端只需要通过一次TCP握手后就可以继续进行后续的请求和响应的过程，而不需要断开连接和继续TCP的三次握手，短连接与长连接在报文的最大的区别是长连接的报文的首部字段多了Connection:keep-alive。

6.2 跨域，CORS，同源策略

6.2.1 跨域

当协议、子域名、主域名、端口号中任意一个不相同时，都算作不同域**。不同域之间相互请求资源，就算作“跨域”。跨域并不是请求发不出去，请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了。之所以会跨域，是因为受到了同源策略的限制，同源策略要求源相同才能正常进行通信，即协议、域名、端口号都完全一致。

6.2.2 CORS

简介：CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。
两种请求 , 浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。只要同时满足以下两大条件，就属于简单请求。

请求方法是以下三种方法之一：
- HEAD
- GET
- POST
（2）HTTP的头信息不超出以下几种字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type：只限于三个值`application/x-www-form-urlencoded`、`multipart/form-data`、`text/plain`

凡是不同时满足上面两个条件，就属于非简单请求。浏览器对这两种请求的处理，是不一样的。
头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

 Access-Control-Allow-Origin: http://api.bob.com
 Access-Control-Allow-Credentials: true
 Access-Control-Expose-Headers: FooBar
 Content-Type: text/html; charset=utf-8

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头

6.2.3 同源策略

同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的关键的安全机制。它的存在可以保护用户隐私信息，防止身份伪造等(读取Cookie)。

同源策略限制内容有：

Cookie、LocalStorage、IndexedDB 等存储性内容
DOM 节点
AJAX 请求不能发送

但是有三个标签是允许跨域加载资源：

1.<img src=XXX> 2.<link href=XXX> 3.<script src=XXX>

6.3 Restful架构

6.3.1 资源与URI

REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

某用户的手机号码
某用户的个人信息
最多用户订购的GPRS套餐
要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。
URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源，只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：
- https://github.com/git
- https://github.com/git/git/pulls?state=closed
使用_或-来让URI可读性更好
曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格，如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
使用/来表示资源的层级关系
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源，指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。
使用?用来过滤资源
很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤，例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求，这种URL通常对应的是一些特定条件的查询结果或算法运算结果。
,或;可以用来表示同级资源的关系
有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。

6.3.2 统一资源接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。

如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的，无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求并不会产生比第一次更多的影响。

post

200（OK）- 如果现有资源已被更改
404 （not found）- 资源不存在
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求

200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
404 （not found）- 资源不存在
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求

6.3.3 资源的表述

客户端获取的只是资源的表述而已。资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。资源的表述包括数据和描述数据的元数据，例如，HTTP头Content-Type就是这样一个元数据属性。

那么客户端如何知道服务端提供哪种表述形式呢?
答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。
一些实践上常见的设计:

在URI里边带上版本号

有些API在URI里边带上版本号，例如:
http://api.example.com/1.0/foo
http://api.example.com/1.2/foo
http://api.example.com/2.0/foo
如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]

对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部:
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.2
Accept: vnd.example-com.foo+json; version=2.0

6.3.4 资源的链接

REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。这种反模式忽略了一个核心概念：“超媒体即应用状态引擎（hypermedia as the engine of application state）”。超媒体是什么?
当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.
要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。

6.3.5 状态的转移

REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?
其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

应用状态与资源状态

实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。
客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。
当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

应用状态的转移

 "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。
 客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。
这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

HTTP学习笔记