We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
简单快速,灵活、无连接、无状态
每一个资源对应一个URI,请求只要输入资源地址uri就可以了; 在每一个http头部协议中都有一个数据类型,通过一个http协议就可以完成不同类型数据的传输; 链接一次就会断开; 每一次链接不会记住链接状态的,服务器不区分两次链接的身份;
请求报文:请求行、请求头、空行、请求体 请求行:HTTP请求方法、页面地址、协议版本等 请求头:key,value值,告诉服务端我要什么内容、要什么数据类型 空行:分割请求头和请求体的,遇到空行,服务器就知道,请求头结束了,接下来是请求体了 请求体:就是给服务端的一些入参数据; 我所了解的请求体有两种格式,Content-Type: application/x-www-form-urlencoded 和 payload 和 json
状态行、响应头、空行、响应体
状态行:协议版本 状态码 状态 其他的一样的
建立在 TCP 之上的
Request Headers
Accept: */* // 告诉服务器,客户机支持的数据类型 Accept-Encoding: gzip, deflate, br // 告诉服务器,客户机支持的数据压缩格式 Accept-Language: zh-CN,zh;q=0.9 // 编码格式 Connection: keep-alive // 是否支持场链接 Content-Length: 12308 // 获取文件的总大小 Content-Type: application/json // 返回数据格式 Host: api.github.com Origin: https://github.com Referer: https://github.com/yanlele/node-index/blob/master/book/05%E3%80%81%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E7%82%B9%E4%B8%93%E9%A2%98/01_01%E3%80%81%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E9%83%A8%E5%88%861-10.md User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Response Headers:
Access-Control-Allow-Origin: * // 允许跨域策略 Access-Control-Expose-Headers: ETag, Link, Location... // 列出了哪些首部可以作为响应的一部分暴露给外部 Cache-Control: no-cache // 缓存失效时间 Content-Length: 5 // 获取文件的总大小 Content-Security-Policy: default-src 'none' // 配置内容安全策略涉 Content-Type: application/json; charset=utf-8 // 返回数据格式 Date: Wed, 21 Nov 2018 09:55:47 GMT Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin Server: GitHub.com Status: 200 OK // 状态码 Strict-Transport-Security: max-age=31536000; includeSubdomains; preload Vary: Accept-Encoding X-Content-Type-Options: nosniff X-Frame-Options: deny X-GitHub-Media-Type: github.v3; format=json X-GitHub-Request-Id: A3D4:2AE5:13372C:19E45C:5BF52BA3 X-XSS-Protection: 1; mode=block
GET请求资源、post传输资源、put更新资源、delete删除资源、head获取报文首部
1.XX:指示信息-表示请求已经接受,继续处理
2.XX:成功 200:请求成功 206:客户端发送一个range头的get请求,服务器完成了他
3.XX:重定向 301:请求的页面转移到新的url; 302:临时转移到新的url 304:客户端缓存的文件并发出了一个条件性的请求,服务器告诉客户,原来缓冲的文档还可以继续使用
4.XX:客户端错误 400:语法错误 401:请求未授权 403:请求禁止访问 404:请求资源不存在
5.XX:服务端错误 500:服务器发生不可预期的错误 503:服务器请求未完成
http采用的是 "请求-应答" 模式 当使用keep-Alive 模式(又称持久链接、链接重用)时、http1.1版本才支持的 Connection: keep-alive
Connection: keep-alive
持久链接下:链接传递消息类似于请求1->响应1->请求2->响应2->请求3->响应3 管线化:请求1-》请求2-》请求3-》响应1-》响应2-》响应3 需要通过持久链接完成,所以仅HTTP1.1版本支持 只有get和head请求支持管线化,post请求是有所限制的
1、客户端。通常是浏览器(Chrome、IE、FireFox等),也可以自己编写的各种语言的客户端程序。 2、服务端。一般指支持Https的网站,比如github、支付宝。 3、CA(Certificate Authorities)机构。Https证书签发和管理机构,比如Symantec、Comodo、GoDaddy、GlobalSign。
图示这三个角色:
认证正在访问的网站。 什么叫认证网站?比如你正在访问支付宝,怎样确定你正在访问的是阿里巴巴提供的支付宝而不是假冒伪劣的钓鱼网站呢? 保证所传输数据的私密性和完整性。 众所周知,Http是明文传输的,所以处在同一网络中的其它用户可以通过网络抓包来窃取和篡改数据包的内容, 甚至运营商或者wifi提供者,有可能会篡改http报文,添加广告等信息以达到盈利的目的。
认证正在访问的网站。
保证所传输数据的私密性和完整性。
可以看到工作流程,基本分为三个阶段:
1、认证服务器。 浏览器内置一个受信任的CA机构列表,并保存了这些CA机构的证书。 第一阶段服务器会提供经CA机构认证颁发的服务器证书,如果认证该服务器证书的CA机构,存在于浏览器的受信任CA机构列表中, 并且服务器证书中的信息与当前正在访问的网站(域名等)一致,那么浏览器就认为服务端是可信的, 并从服务器证书中取得服务器公钥,用于后续流程。 否则,浏览器将提示用户,根据用户的选择,决定是否继续。 当然,我们可以管理这个受信任CA机构列表,添加我们想要信任的CA机构,或者移除我们不信任的CA机构。
认证服务器。
2、协商会话密钥。 客户端在认证完服务器,获得服务器的公钥之后,利用该公钥与服务器进行加密通信, 协商出两个会话密钥,分别是用于加密客户端往服务端发送数据的客户端会话密钥,用于加密服务端往客户端发送数据的服务端会话密钥。 在已有服务器公钥,可以加密通讯的前提下,还要协商两个对称密钥的原因,是因为非对称加密相对复杂度更高,在数据传输过程中,使用对称加密,可以节省计算资源。 另外,会话密钥是随机生成,每次协商都会有不一样的结果,所以安全性也比较高。
协商会话密钥。
**3、加密通讯。**此时客户端服务器双方都有了本次通讯的会话密钥,之后传输的所有Http数据,都通过会话密钥加密。 这样网路上的其它用户,将很难窃取和篡改客户端和服务端之间传输的数据,从而保证了数据的私密性和完整性。
加密通讯。
说是讨论Https,事实上Https就是Http跑在SSL或者TLS上,所以本文讨论的原理和流程其实是SSL和TLS的流程,对于其它使用SSL或者TLS的应用层协议,本文内容一样有效。 本文只讨论了客户端验证服务端,服务端也可以给客户端颁发证书并验证客户端,做双向验证,但应用没有那么广泛,原理类似。 由于采用了加密通讯,Https无疑要比Http更耗费服务器资源,这也是很多公司明明支持Https却默认提供Http的原因。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
http 协议有什么特点?
简单快速,灵活、无连接、无状态
每一个资源对应一个URI,请求只要输入资源地址uri就可以了;
在每一个http头部协议中都有一个数据类型,通过一个http协议就可以完成不同类型数据的传输;
链接一次就会断开;
每一次链接不会记住链接状态的,服务器不区分两次链接的身份;
http报文组成部分?
请求报文
请求报文:请求行、请求头、空行、请求体
请求行:HTTP请求方法、页面地址、协议版本等
请求头:key,value值,告诉服务端我要什么内容、要什么数据类型
空行:分割请求头和请求体的,遇到空行,服务器就知道,请求头结束了,接下来是请求体了
请求体:就是给服务端的一些入参数据;
我所了解的请求体有两种格式,Content-Type: application/x-www-form-urlencoded 和 payload 和 json
相应报文
状态行、响应头、空行、响应体
状态行:协议版本 状态码 状态
其他的一样的
通信协议?
建立在 TCP 之上的
常见请求头数据和相应头数据(以github某请求为例子)
Request Headers
Response Headers:
HTTP方法相关?
GET请求资源、post传输资源、put更新资源、delete删除资源、head获取报文首部
get和post区别
http 常见状态码有哪些?
1.XX:指示信息-表示请求已经接受,继续处理
2.XX:成功
200:请求成功
206:客户端发送一个range头的get请求,服务器完成了他
3.XX:重定向
301:请求的页面转移到新的url;
302:临时转移到新的url
304:客户端缓存的文件并发出了一个条件性的请求,服务器告诉客户,原来缓冲的文档还可以继续使用
4.XX:客户端错误
400:语法错误
401:请求未授权
403:请求禁止访问
404:请求资源不存在
5.XX:服务端错误
500:服务器发生不可预期的错误
503:服务器请求未完成
什么是 HTTP持久链接?
http采用的是 "请求-应答" 模式
当使用keep-Alive 模式(又称持久链接、链接重用)时、http1.1版本才支持的
Connection: keep-alive
什么是管线化?
持久链接下:链接传递消息类似于请求1->响应1->请求2->响应2->请求3->响应3
管线化:请求1-》请求2-》请求3-》响应1-》响应2-》响应3
需要通过持久链接完成,所以仅HTTP1.1版本支持
只有get和head请求支持管线化,post请求是有所限制的
深入研究 HTTPS
Https涉及到的主体:
1、客户端。通常是浏览器(Chrome、IE、FireFox等),也可以自己编写的各种语言的客户端程序。
2、服务端。一般指支持Https的网站,比如github、支付宝。
3、CA(Certificate Authorities)机构。Https证书签发和管理机构,比如Symantec、Comodo、GoDaddy、GlobalSign。
图示这三个角色:
发明 Https 的动机:
认证正在访问的网站。
什么叫认证网站?比如你正在访问支付宝,怎样确定你正在访问的是阿里巴巴提供的支付宝而不是假冒伪劣的钓鱼网站呢?保证所传输数据的私密性和完整性。
众所周知,Http是明文传输的,所以处在同一网络中的其它用户可以通过网络抓包来窃取和篡改数据包的内容,甚至运营商或者wifi提供者,有可能会篡改http报文,添加广告等信息以达到盈利的目的。
Https的工作流程
可以看到工作流程,基本分为三个阶段:
1、
认证服务器。
浏览器内置一个受信任的CA机构列表,并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书,如果认证该服务器证书的CA机构,存在于浏览器的受信任CA机构列表中,
并且服务器证书中的信息与当前正在访问的网站(域名等)一致,那么浏览器就认为服务端是可信的,
并从服务器证书中取得服务器公钥,用于后续流程。
否则,浏览器将提示用户,根据用户的选择,决定是否继续。
当然,我们可以管理这个受信任CA机构列表,添加我们想要信任的CA机构,或者移除我们不信任的CA机构。
2、
协商会话密钥。
客户端在认证完服务器,获得服务器的公钥之后,利用该公钥与服务器进行加密通信,协商出两个会话密钥,分别是用于加密客户端往服务端发送数据的客户端会话密钥,用于加密服务端往客户端发送数据的服务端会话密钥。
在已有服务器公钥,可以加密通讯的前提下,还要协商两个对称密钥的原因,是因为非对称加密相对复杂度更高,在数据传输过程中,使用对称加密,可以节省计算资源。
另外,会话密钥是随机生成,每次协商都会有不一样的结果,所以安全性也比较高。
**3、
加密通讯。
**此时客户端服务器双方都有了本次通讯的会话密钥,之后传输的所有Http数据,都通过会话密钥加密。这样网路上的其它用户,将很难窃取和篡改客户端和服务端之间传输的数据,从而保证了数据的私密性和完整性。
总结
说是讨论Https,事实上Https就是Http跑在SSL或者TLS上,所以本文讨论的原理和流程其实是SSL和TLS的流程,对于其它使用SSL或者TLS的应用层协议,本文内容一样有效。
本文只讨论了客户端验证服务端,服务端也可以给客户端颁发证书并验证客户端,做双向验证,但应用没有那么广泛,原理类似。
由于采用了加密通讯,Https无疑要比Http更耗费服务器资源,这也是很多公司明明支持Https却默认提供Http的原因。
The text was updated successfully, but these errors were encountered: