简介

精彩点评

• 

  Aurora

  推荐

  浏览器地址栏输入地址到页面渲染完成发生了什么?  1.浏览器进行地址解析，获取该地址的端口号、域名、协议、路径等信息。  2.将解析的域名进行DNS解析。  3.通过ip地址寻找服务器地址  4.与服务器进行三次握手建立连接  5.浏览器发送数据，等待服务器的响应  6.服务器响应并返回数据  7.浏览器接收到数据  8.浏览器开始渲染页面 URI与URL URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。  URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。 HTTP1.0和HTTP1.1的区别  1.长连接 -- HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。HTTP1.0每次请求都要创建连接。  2.节约带宽 -- HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。 HOST域 -- 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名，HTTP1.0没有host域。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。  3.缓存处理 -- 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。  4. 错误通知的管理 -- 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。  HTTP1.1和HTTP2.0的区别  1.多路复用 --HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。 头部数据压缩 -- HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。  2.服务器推送 -- 服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。 五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层  1.应用层：直接为用户的应用进程（例如电子邮件、文件传输和终端仿真）提供服务。  相关协议：HTTP、FTP、DNS、SMTP、Telnet等  2.运输层：负责向两个主机中进程之间的通信提供服务。由于一个主机可同时运行多个进程，因此运输层有复用和分用的功能  相关协议：TCP、UDP等  3.网络层：在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择  相关协议：IP、ICMP等  4.数据链路层：定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。  相关协议：ARP、RARP等  5.物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流。 三次握手：  1、第一次握手：客户端给服务器发送一个 SYN 报文。  2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。  3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。  4、服务器收到 ACK 报文之后，三次握手建立完成。  四次挥手：  1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。 2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。 3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。  4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态 5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。 DNS域名解析过程：  1.在浏览器中输入域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。  2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。  3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。  4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析。  5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。  6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。 http协议格式 请求报文：请求报头+空行+实体 响应报文：响应报头+空行+实体 请求报头：请求行+报头（请求首部+通用首部+实体首部） 响应报头：响应状态行+报头（响应首部+通用首部+实体首部） 报头首部类型：请求首部、响应首部、通用首部、实体首部 资源表述性状态转移 根据数据抽象出来的资源，以某种表现形式，通过某种手段，在网络中发生状态转移，以此来间接实现操作资源的目的。 如果一个架构符合REST原则，就称它为RESTful架构。  1.每一个URI代表一种资源；  2.客户端和服务器之间，传递这种资源的某种表现层；  3.客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。 使用 cookie 时需要考虑的问题:  1.因为存储在客户端，容易被客户端篡改，使用前需要验证合法性  2.不要存储敏感数据，比如用户密码，账户余额  3.使用 httpOnly 在一定程度上提高安全性  4.尽量减少 cookie 的体积，能存储的数据量不能超过 4kb  5.设置正确的 domain 和 path，减少数据传输  6.cookie 无法跨域  7.一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie  8.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token  使用 session 时需要考虑的问题:  1.将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session  2.session 是由单个服务器创建的,当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。  3.当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。 4.sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie,一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现  5.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token  使用 token 时需要考虑的问题:  1.如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。  2.token 完全由应用管理，所以它可以避开同源策略  3.token 可以避免 CSRF 攻击  4.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token HTTP/1.1首部字段 1.首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。 2.使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。Via首部是为了追踪传输路径，所以经常会和TRACE方法一起使用。 3.Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级 4.Accept-Charset首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。 5.Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序 6.Accept-Language用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级 7.Authorization是用来告知服务器，用户代理的认证信息（证书值） 8.Expect来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417 Expectation Failed。 9.From用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式 10.Host会告知服务器，请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。 11.Referer会告知服务器请求的原始资源的URI。 12.User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。 13.Content-Type说明了实体主体内对象的媒体类型

• 

  没名字

  推荐

  https认证模块讲解的比较精彩，网络安全稍微提了个大概。对粗识http协议有帮助。

• 

  热爱

  推荐

  之前看过纸质版的，于自己而言算是查漏补缺，书中很多东西还是要结合实际场景方能理解更深刻，不推荐新手直接看此书。

• 

  静待花开（褚思颉爸爸）

  推荐

  这是HTTP协议的入门级图书，适合对网络协议感兴趣的朋友们阅读，可以俯视浏览到整个HTTP协议的全貌，但是对于不了解网络的朋友会有一点困难。

• 

  陈阿满

  推荐

  书名：图解HTTP 类型：计算机专业书籍 作者简介 ：上野宣，OWASP日本分会会长，TRICORDER株式会社董事长。主要从事安全咨询、风险评估、信息安全教育等工作，著有<今晚我们一起学习邮件协议>、<今晚我们一起学习TCP/IP>、<今晚我们一起学习HTTP>等。 点评： 依稀记得2014年的时候，我曾花费了至少一个星期的时间去系统学习Http的知识，以期待对Http协议有一个全面的认知。一则是因为http协议是一门基础知识，到处会有使用；一则是能够忽悠面试官，不会显得啥都不会。 自以为当时整理的Http知识很全面：有请求报头合适，有响应报头格式，有各种类型的报头以及他们的详细说明，有各种响应状态码及其含义。当然也有考虑到安全的问题，比如Https协议、各种Web攻击等，但是也都是只言片语，写的很浅。 现在读完本书才发现，这本书原来就是我当时希望看到的书，书中所涵盖的内容，比我自己总结的内容更加全面，而且更加浅显易懂。真是相见恨晚，或许这本书在2013年而不是2014年出版，会省去我不少事情。 所有的技术方案都是为了解决特定的问题而存在，问题不在了也就不存在所谓的技术。所以学习技术的首要事情是：了解所面临的问题。 好了，闲话不多扯了，做个笔记，下次看的时候可以更快。 1. http版本 Http于1990年问世，那时的HTTP并没有作为正式的标准被建立。这时的HTTP其实含有HTTP/ 1.0之前版本的意思，因此被称为HTTP/0.9。 HTTP正式作为标准被公布是在1996年的5月，版本被命名为HTTP/1.0，并记载于RFC1945。 1997年1月公布的HTTP/1.1是目前主流的HTTP协议版本。 HTTP2.0是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协定。它由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。[2]该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论[3]，于2015年2月17日被批准。 2. http各个版本之间的区别 方面HTTP协议的出现主要是为了解决文本传输的难题。 HTTP是一种不保存状态，即无状态（stateless）协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。 HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。 HTTP主要有这些不足：通信使用明文（不加密），内容可能会被窃听；不验证通信方的身份，因此有可能遭遇伪装；无法证明报文的完整性，所以有可能已遭。Https就是为了解决这些问题而存在。 HTTP+加密+认证+完整性保护=HTTPS。 HTTP标准的瓶颈： 一条连接上只可发送一个请求。 ●请求只能从客户端开始。客户端不可以接收除响应以外的指令。 ●请求/响应首部未经压缩就发送。首部信息越多延迟越大。 ●发送冗长的首部。每次互相发送相同的首部造成的浪费较多。 ●可任意选择数据压缩格式。非强制压缩发送 为了解决这些问题就出现了SPDY协议。Http2.0基于SPDY协议实现的。 3. http协议格式 请求报文：请求报头+空行+实体 响应报文：响应报头+空行+实体 请求报头：请求行+报头（请求首部+通用首部+实体首部） 响应报头：响应状态行+报头（响应首部+通用首部+实体首部） 报头首部类型：请求首部、响应首部、通用首部、实体首部 有哪些报头，都什么作用，自己看。 请求方法有哪些自己看 响应状态码有哪些自己看 4. 代理、网关、隧道的区别 代理是黄牛，倒买倒卖，手上沾点油。不改动，服务端一定使用的是Http。比如一般的CDN服务器。 网关是一个人工服务员，对外提供统一的服务，客户不用与各种内部接口人一一对接。网关的上游服务器可能使用的是ftp、mail等非http协议。比如三大电影运营商。 隧道也是一个秘密的暗道，其他人没法窥探里面的内容。比如shadowsocket 5. CA认证机构 https协议会使用非对称加密，但非对称加密中公开密钥存在的身份认证问题，即怎么证明我是我的问题。这个时候就出现了第三者：CA认证机构。所有需要使用数字签名的网站，就把身份认证的事情交给CA来完成。 那么CA认证机构也出现一个尴尬的问题。怎么证明自己是自己的问题。你CA是假的怎么办？那么这个时候的解决办法就是将所有顶级的CA的公钥在浏览器里面都内置一份。对的，每个浏览器在出厂的时候，都会存一些CA认证机构的照片，这样就假不了了。 6. 关于SSL SSL技术最初是由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之前的版本。目前主导权已转移到IETF（Internet Engineering Task Force,Internet工程任务组）的手中。 IETF以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0 SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。这个就是SSL鸡肋之处。所以Https的使用就需要考虑成本的问题。 7. 服务器端考虑的几个问题 怎么省流量？怎么减少机器资源的消耗？怎么保证缓存一致性？怎么保证可靠性？怎么保证拓展性，保证各个业务分离？简言之，快、稳、省、准。 8. 关于Web完全 There is a door，there is a way！ 有和外部交互的地方，那么就存在安全问题的可能。只要外部能够把数据送到你服务端，那么就存在安全风险的可能。具体就可能是怎么把数据送进去的问题了。 有的可能是通过在客户端入手，把私货夹带进入；而有的是路上动手，中间人劫持；还有人是直接在服务端动手，破解你root权限；发一份钓鱼邮件，先送到你内网再说，你点开了，那么这个雷就埋好了。 当然上述都是主动劫持，还有被动劫持。那么就是对用户下手。 发一发钓鱼网站，添加XSS跨域攻击，把用户的信息在不知不觉中上传到黑客的网站上。 当然说的很轻巧，这些都是要找到代码的漏洞，必须熟悉各种方式，然后才能知道会存在哪些bug。这条路很长很长。 差点忘了，我原来还是个程序员～