初识http

初识http

在刚刚开始学习前端ajax时，经常听说http协议，“不就是三次握手，四次挥手吗？”，一番言语过后。似懂非懂。近期由于开始学习nodejs，借此机会开始学习了一波http

什么是http?

从其英文全意来看，是HyperText Transfer Protocol，中文解释是超文本传输协议。那什么又是超文本？。在wiki上解释是：

超文本（英语：Hypertext）是一种在电脑显示器或其他电子设备，用以显示文本及与文本相关的内容，其中的文字包含有可以链接到其他字段或者文档的超链接，允许从当前阅读位置直接切换到超链接所指向的文字。万维网的架构便是以超文本的底层概念定义为基础。

因此，从概念上来看，http最初的目的就是为了提供一种发布和接收HTML页面的方法。

http包含了那些方法？

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。参见安全方法

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求，主要用于测试或诊断。

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*’来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。例如：

PATCH（由 RFC 5789 指定的方法）

用于将局部修改应用到资源。

一般来说，我们常用的有GET,POST,DELETE,PUT四个方法。大多数情况用于获取，增改，删除以及传输文件。

http包含那些内容？

大体上，包含报文首部，报文主体。

报文首部

报文首部由于请求以及响应的报文首部。

请求报文首部。

请求行：包含用于请求的方法，请求URI以及HTTP版本
首部字段:包含表示请求和响应的各种条件和属性的各类首部。一般有四种首部，分别是：请求首部、响应首部、通用首部以及实用首部
其他：可能包含HTTP里为定义RFC的首部(Cookie等)

响应报文首部

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

报文主体

报文主体和报文首部是分开的。由换行分开报文首部以及报文主体。

返回结果的常用HTTP状态码

状态码	类别	原因短语
1xx	Informational(信息性状态码)	接受的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作以完成请求
4xx	Client Error(客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务器端错误状态码)	服务器处理请求出错

1XX 消息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。

2XX 成功

200 Ok

请求已成功，请求所希望的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在GET请求中，响应将包含与请求的资源相对应的实体。在POST请求中，响应将包含描述或操作结果的实体。

204 No Content

服务器成功处理了请求，没有返回任何内容。

206 Partial Content

服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。

3XX 重定向

301 Moved Permanently

被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。

302 Found

要求客户端执行临时重定向（原始描述短语为“Moved Temporarily”）。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。因此状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。

303 See Other

对应当前请求的响应可以在另一个URI上被找到，当响应于POST（或PUT / DELETE）接收到响应时，客户端应该假定服务器已经收到数据，并且应该使用单独的GET消息发出重定向。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。
新的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
注意：许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

304 Not Modified

表示资源未被修改，因为请求头指定的版本If-Modified-Since或If-None-Match。在这种情况下，由于客户端仍然具有以前下载的副本，因此不需要重新传输资源。

307 Temporary Redirect

在这种情况下，请求应该与另一个URI重复，但后续的请求应仍使用原始的URI。 与302相反，当重新发出原始请求时，不允许更改请求方法。 例如，应该使用另一个POST请求来重复POST请求。

4XX客户端错误

400 Bad Request

由于明显的客户端错误（例如，格式错误的请求语法，太大的大小，无效的请求消息或欺骗性路由请求），服务器不能或不会处理该请求

401 Unauthorized

用户没有必要的凭据。该状态码表示当前请求需要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了Authorization证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。

403 Forbidden

服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个HEAD请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。

404 Not Found

请求失败，请求所希望得到的资源未被在服务器上发现，但允许用户的后续请求。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

5XX服务器错误

500 Internal Server Error

通用错误消息，服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。没有给出具体错误信息。

503 Service Unavailable

由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是暂时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个Retry-After头用以标明这个延迟时间。如果没有给出这个Retry-After信息，那么客户端应当以处理500响应的方式处理它。

HTTP的应用

三次握手，四次挥手

哪三次握手？以一个小段子来解释。
第一次握手：A确定B是不是知道A喜欢他;问：‘你是不是喜欢我啊？’
第二次握手：B告诉A他很喜欢她，并且反问;答：‘我喜欢你啊，你喜欢我吗？’
第三次握手：A告诉B;说：‘我喜欢你啊，那我们在一起吧。。。’
于是他们就在一起了。
这就是经典的三次握手
那又是哪四次挥手呢？
第一次说：A告诉B她不喜欢他了;说：‘我已经不喜欢你了，我们分手吧。’
第二次说：B告诉A说也不喜欢她了;说：’我知道了，我也不喜欢你了，我们分手吧。‘
第三次说：A告诉B说他已经知道了：’我知道了，那我们分手吧。‘
第四次说：B告诉A说他已经知道了A的心意：’我知道了，那我们就分手吧。‘
于是他们因此分手。

为什么是三次握手呢？
在知乎上看到一个人这样答道：
这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足”在不可靠信道上可靠地传输信息”这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.
为了满足数据的可靠性。因而才设置三次握手。我想，大概四次挥手也是这个原理吧

http有不满足现代web发展的需求？

http是上个世纪的产物，到达21世纪之后，http的功能已经捉襟见肘。因此，有了扩展的http，https。

什么是HTTPS

https并不是新型产物，而是http Secure，是更安全版本。在其基础上加了一层ssl层。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

为什么要HTTPS

由于普通的http协议会经过多层代理服务器，因此可能在通讯过程中的数据的泄密和被篡改。也可能遭到非法入侵。因此，为了更好的用户保密，以及确定用户身份。有了ssl层。
ssl释义：
SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。
因此，ssl保证了http的安全性。也由于其多层的访问确认关系，要比正常的http慢2-100倍

总结：

初识http让我从前端思维到后端思维的一个过渡。逐渐解密在数据传输过程中的小黑匣。http状态码以及其工作原理也十分重要的体现在我日常工作中。后端的思维过渡以及前端的新层面让我了然于胸。初识http，重新认识了互联网。