HTTP协议

在 OSI 七层模型中，HTTP 协议位于最顶层的应用层中。通过浏览器访问网页就直接使用了 HTTP 协议。使用 HTTP 协议时，客户端首先与服务端的 80 端口建立一个 TCP 连接，然后在这个连接的基础上进行请求和应答，以及数据的交换。

HTTPS协议

HTTP 有两个常用版本，分别是 1.0 和 1.1。主要区别在于 HTTP 1.0 中每次请求和应答都会使用一个新的 TCP 连接，而从 HTTP 1.1 开始，运行在一个 TCP 连接上发送多个命令和应答。因此大幅度减少了 TCP 连接的建立和断开，提高了效率。

由 HTTP 协议加载出来的网页，通常使用 HTML 语言来描述，因此 HTML 也可以理解为网页的一种数据格式。HTML 是一段纯文本，可以指定网页中的文字、图像、音频视频图片、链接，以及它们的颜色、位置等。无论计算机的底层结构如何，也无论网络底层使用了哪些协议，使用 HTML 展示出来的效果基本上是一致的。从这个角度来说 HTML 位于 OSI 七层模型的表现层。

POST 请求和 GET 请求

HTTP 有八种请求（也称方法），其中最常见的是 GET 请求和 POST 请求。
GET 请求通常用于查询、获取数据，而 POST 请求则用于发送数据，除了用途上的区别，它们还有以下这些不同：

• GET 请求可以被缓存，可以被收藏为书签，但 POST 不行。
• GET 请求会保留在浏览器的历史记录中，POST 不会。
• GET 请求的长度有限制（不同的浏览器不一样，大约在几 Kb 左右），URL 的数据类型只能是 ASCII 字符，POST 请求没有限制。
• GET 请求的参数在 URL 中，因此绝不能用 GET 请求传输敏感数据。POST 请求数据则写在 HTTP 的请求头中，安全性略高于 GET 请求。
• 在以下情况中，请使用 POST 请求：
  无法使用缓存文件（更新服务器上的文件或数据库）
  向服务器发送大量数据（POST 没有数据量限制）
  发送包含未知字符的用户输入时，POST 比 GET 更稳定也更可靠
  Post比Get安全性更高

注意：

POST 请求仅比 GET 请求略安全一点，它的数据不在 URL 中，但依然以明文的形式存放于 HTTP 的请求头中。

Cookie 和 Session

HTTP 是一种无状态的连接，客户端每次读取 web 页面时，服务器都会认为这是一次新的会话。但有时候我们又需要持久保持某些信息，比如登录时的用户名、密码，用户上一次连接时的信息等。这些信息就由 Cookie 和 Session 保存。让HTTP服务器和客户之间传递状态信息

使用 Cookie 的网站服务器为用户产生一个唯一的识别码。利用此识别码，网站就能够跟踪该用户在该网站的活动。

这两者的根本性区别在于，cookie 保存在客户端上，而 session 则保存在服务器中。由此我们还可以拓展出以下结论：

• cookie 相对来说不安全，浏览器可以分析本地的 cookie 进行 cookie 欺骗。
• session 可以设置超时时间，超过这个时间后就失效，以免长期占用服务端内存。
• 单个 cookie 的大小有限制（4 Kb），每个站点的 cookie 数量一般也有限制（20个）。
• 客户端每次都会把 cookie 发送到服务端，因此服务端可以知道 cookie，但是客户端不知道 session。
• 当服务器接收到 cookie 后，会根据 cookie 中的 SessionID 来找到这个客户的 session。如果没有，则会生成一个新的 SessionID 发送给客户端。

HTTP响应消息中的状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx : 请求已经接受，需要继续处理。
2xx : 请求已经被服务器接收、理解 
      200 OK 
      请求已成功，请求所希望的响应头或数据体将随此响应返回。
3xx : 重定向--要完成请求必须进行更进一步的操作
4xx : 客户端错误--请求有语法错误或请求无法实现
      400 bad request 由于包含语法错误，当前请求无法被服务器理解。
      除非进行修改，否则客户端不应该重复提交这个请求。 
      401 unauthorized 当前请求需要用户验证。 
      403 Forbbiden 服务器已经理解请求，但是拒绝执行它。 
      404 Not Found 请求失败，请求所希望得到的资源未被在服务器上发现。
       没有信息能够告诉用户这个状况到底是暂时的还是永久的 
      405 Method Not Allowed 请求行中指定的请求方法不能被用于请求相应的资源。 
      该响应必须返回一个 Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 
      鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作， 
      因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法， 
      对于此类请求均会返回 405 错误。
5xx : 服务器错误 
      503 Service Unavailable 
      由于临时的服务器维护或者过载，服务器当前无法处理请求。 
      这个状况是临时的，并且将在一段时间以后恢复。 
      如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。 
      如果没有给出这个 Retry-After 信息，那么客户端应当以处理 500 响应的方式处理它。 

      505 HTTP Version Not Supported 
      服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。

加密

加密分为两种，对称加密和非对称加密。在解释这两者的含义前，先来看一下简单的加密、解密过程：

所谓的对称，就是指加密秘钥和解密秘钥相同，而非对称自然就是指两者不同。
举一个对称加密的例子。假设这里的加密算法是加法，解密算法是减法。如果明文数据是 10，秘钥是 1，那么加密数据就是10 + 1 = 11，如果接收方不知道秘钥，就不知道密文 11 应该减去几。反之，如果接收方知道秘钥是 1，就可以通过11 - 1 = 10
计算出明文数据。
常见的一个非对称加密算法是 RSA 算法，它主要利用了“两个素数求乘积容易，但是将乘积分解为两个素数很难”这一思想。它的具体原理不在本文讨论范围，有兴趣的读者可以查看文章末尾的参考文章。
在非对称加密中，利用公钥加密的数据能且只能通过私钥解密，通过私钥加密的数据能且只能通过公钥解密。
对称加密的优点在于速度快，但是假设秘钥由服务器保存，如何安全的让客户端得到秘钥是需要解决的问题。因此实际的网络传输中，通常使用对称加密与非对称加密结合的方式，服务端通过非对称加密将对称秘钥发给客户端。此后双方使用这个对称密钥进行通信。

HTTPS

我们知道 HTTP 协议直接使用了 TCP 协议进行数据传输。由于数据没有加密，都是直接明文传输，所以存在以下三个风险：
窃听风险：第三方节点可以获知通信内容。
篡改风险：第三方节点可以修改通信内容。
冒充风险：第三方节点可以冒充他人身份参与通信。

比如你在手机上打开应用内的网页时，有时会看到网页底部弹出了广告，这实际上就说明你的 HTTP 内容被窃听、并篡改了。
HTTPS 协议旨在解决以上三个风险，因此它可以：
保证所有信息加密传输，无法被第三方窃取。
为信息添加校验机制，如果被第三方恶意破坏，可以检测出来。
配备身份证书，防止第三方伪装参与通信。

HTTPS 的结构如图所示：

HTTPS 协议

可见它仅仅是在 HTTP 和 TCP 之间新增了一个 TLS/SSL 加密层，这也印证了一句名言：“一切计算机问题都可以通过添加中间层解决”。
使用 HTTPS 时，服务端会将自己的证书发送给客户端，其中包含了服务端的公钥。基于非对称加密的传输过程如下：
客户端使用公钥将信息加密，密文发送给服务端
服务端用自己的私钥解密，再将返回数据用私钥加密发回客户端
客户端用公钥解密

HTTP和HTTPS的区别

• HTTP是HTTP协议运行在TCP之上。所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
• HTTPS是HTTP运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。
  -HTTPS协议需要到ca申请证书，一般免费证书很少，需要交费。
• HTTP是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
• HTTP和HTTPS使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
• HTTP的连接很简单,是无状态的
• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全

TCP如何保证可靠传输？

• TCP如何保证可靠传输
  1. 数据包校验
  2. 超时重传机制
  3. 应答机制
  4. 对失序数据包重排序
  5. TCP还能提供流量控制

TCP状态转移图

TCP状态转移图

三次握手

三次握手及四次挥手过程

• 3次握手过程状态：
• LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
• SYN_SENT: 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。（发送端）
• SYN_RCVD: 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。（服务器端）
• ESTABLISHED：这个容易理解了，表示连接已经建立了。
• 为什么TCP连接需要三次握手，两次不可以吗，为什么
  • 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
  • 例子 （发送连接请求延迟到达服务器端）

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

• 三次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
• 把三次握手改成仅需要两次握手，死锁是可能发生的（服务器端确认连接的包丢失）

考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

• 三次握手的漏洞及攻击
  • 如果客户端不断的发送请求连接会怎样？
    服务器端回为每个请求创建一个链接，然后向client端发送创建链接时的回复，然后进行等待客户端发送第三次握手数据包，这样会白白浪费资源
• DDos攻击
  简单的说就是想服务器发送链接请求，首先进行
  第一步：客户端向服务器端发送连接请求数据包（1）
  第二步：服务器向客户端回复连接请求数据包（2），然后服务器等待客户端发送tcp/ip链接的第三步数据包(3)
  第三步：如果客户端不向服务器端发送最后一个数据包(3)，则服务器须等待30s到2min中才能将此链接进行关闭。当大量的请求只进行到第二步，而不进行第三步，服务器又大量的资源等待第三个数据包。则造成DDos攻击。

DDoS究竟如何攻击?目前最流行也是最好用的攻击方法就是使用SYN-Flood进行攻击，SYN-Flood也就是SYN洪水攻击。SYN-Flood不会完成TCP三次握手的第三步，也就是不发送确认连接的信息给服务器。这样，服务器无法完成第三次握手，但服务器不会立即放弃，服务器会不停的重试并等待一定的时间后放弃这个未完成的连接，这段时间叫做SYN timeout，这段时间大约30秒-2分钟左右。

若是一个用户在连接时出现问题导致服务器的一个线程等待1分钟并不是什么大不了的问题，但是若有人用特殊的软件大量模拟这种情况，那后果就可想而知了。一个服务器若是处理这些大量的半连接信息而消耗大量的系统资源和网络带宽，这样服务器就不会再有空余去处理普通用户的正常请求(因为客户的正常请求比率很小)。这样这个服务器就无法工作了，这种攻击就叫做:SYN-Flood攻击。
SYN-FLOOD是一种常见的DDos攻击，拒绝服务攻击。通过网络服务所在的端口发送大量伪造原地址的攻击报文，发送到服务端，造成服务端上的半开连接队列被占满，从而阻止其他用户进行访问。它的数据报特征是大量syn包，并且缺少最后一步的ACK回复。
攻击原理：攻击者首先伪造地址，对服务器发起syn请求，服务器回应syn+ACK，而真实的IP会认为我没有发送请求，不做回应，而服务端没有收到回应，服务器就不知道是否发送成功，默认情况下重试5次 syn_retries，这样的话，对于服务器内存和带宽有很大的消耗。

• 解决SYN FLOOD方法
• (1).无效连接监控
  不停监视半开连接和不活动连接，当半开连接数和不活动连接数到达一定值时候，就释放系统资源。 伤敌1000，自损8000
• (2).延缓TCB方法
  SYN FLOOD的关键是利用了，syn数据报一到，系统就分配TCB资源。
  那么我们有两种方法资源问题：
  • Syn cache
    这种技术在收到Syn时不急着分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中保存这种连接，直到收到正确的ACK，才分配TCB。
  • Syn Cookie
    用一种特殊的算法生成sequence number，算法考虑到对方的信息和己方信息，收到对方的ACK报文后，验证之后才决定是否生成TCB
• DDos预防(这种攻击的特点是它利用了TCP/IP协议的漏洞，除非你不用TCP/IP，才有可能完全抵御住DDoS攻击)
  • 确保服务器的系统文件是最新版本，并及时更新系统补丁
  • 关闭不必要的服务
  • 限制同时打开SYN的半连接数目
  • 缩短SYN半连接的time out时间
  • 正确设置防火墙
  • 禁止对主机的非开放服务的访问
  • 限制特定IP短地址的访问
  • 启用防火墙的防DDos的属性
  • 严格限制对外开放的服务器的向外访问
  • 运行端口映射程序祸端口扫描程序，要认真检查特权端口和非特权端口。
    认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更，那这台机器就可能遭到了攻击。
  • 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。

四次挥手

四次挥手过程

• 四次挥手过程状态:
  • FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
• FIN_WAIT_2：实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须FIN_WAIT_2状态。（主动方）
• FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经FIN_WAIT_2状态。（主动方）
• CLOSING（比较少见）: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
• CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
• LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）

• CLOSED: 表示连接中断。

  
  
  四次挥手过程图看着也行
• 为什么四次挥手
  解释原因：

TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.
关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.

另一种解释：

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

• 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

  • 什么是2MSL？
    MSL即Maximum Segment Lifetime，也就是报文最大生存时间，引用《TCP/IP详解》中的话：“它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么，2MSL也就是这个时间的2倍，当TCP连接完成四个报文段的交换时，主动关闭的一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束。
    例如在上面的telnet程序客户端关闭后，使用netstat查看的结果:
    C:\>netstat -na | find "172.29.21.25"TCP 172.29.132.60:2795 172.29.21.25:23 TIME_WAIT

• 为什么需要这个2MSL：

  • 第一，虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
  • 第二，报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。

直接引用《The TCP/IP Guide》的说法：The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.

 **当某个连接的一端处于TIME_WAIT状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的是，这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时，这意味着这个TCP连接并没有断开(完全断开)，那么，如果你bind这个端口，就会失败。**对于服务器而言，如果服务器突然crash掉了，那么它将无法在2MSL内重新启动，因为bind会失败。解决这个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。

TCP和UDP区别？如何改进TCP

• TCP和UDP区别
• UDP 是无连接的，即发送数据之前不需要建立连接。
• UDP 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
• UDP 是面向报文的。UDP 没有拥塞控制，很适合多媒体通信的要求。
• UDP 支持一对一、一对多、多对一和多对多的交互通信。
• UDP 的首部开销小，只有 8 个字节。
• TCP 是面向连接的运输层协议。
• 每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一）。
• TCP 提供可靠交付的服务。
• TCP 提供全双工通信。
• TCP是面向字节流。
• 首部最低20个字节。
• TCP加快传输效率的方法 ：采取一块确认的机制

TCP：面向连接、字节流和可靠传输
UDP:无连接、数据包、不可靠传输
字节流的概念：发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系，这就是字节流的概念

滑动窗口算法

http://coolshell.cn/articles/11609.html

TCP的拥塞控制 – Congestion Handling

• 在计算机网络中的链路容量（带宽）、交换结点的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。 -- 这种情况叫做拥塞。
• 出现资源拥塞的条件：
  对资源需求的总和 > 可用资源
• 拥塞控制与流量控制的关系
  拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络符合。
• 拥塞控制与流量控制的区别
• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
• 流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制
  流量控制所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。
• 拥塞控制的方法
  1）慢启动，2）拥塞避免，3）拥塞发生，4）快速恢复。

从输入网址到获得页面的过程

• 查询DNS，获取域名对应的IP地址
• 浏览器搜索自身的DNS缓存
• 搜索操作系统的DNS缓存
• 读取本地的HOST文件
• 发起一个DNS的系统调用
• 宽带运营服务器查看本身缓存
• 运营商服务器发起一个迭代DNS解析请求
• 浏览器获得域名对应的IP地址后，发起HTTP三次握手
• TCP/IP连接建立起来后，浏览器就可以向服务器发送HTTP请求了
• 服务器接受到这个请求，根据路径参数，经过后端的一些处理生成HTML页面代码返回给浏览器
• 浏览器拿到完整的HTML页面代码开始解析和渲染，如果遇到引用的外部JS，CSS,图片等静态资源，它们同样也是一个个的HTTP请求，都需要经过上面的步骤
• 浏览器根据拿到的资源对页面进行渲染，最终把一个完整的页面呈现给用户

用户点击鼠标后所发生的事件

(1) 浏览器分析超链指向页面的 URL。
(2) 浏览器向 DNS 请求解析 www.tsinghua.edu.cn 的 IP 地址。
(3) 域名系统 DNS 解析出清华大学服务器的 IP 地址。
(4) 浏览器与服务器建立 TCP 连接
(5) 浏览器发出取文件命令： GET /chn/yxsz/index.htm。
(6) 服务器给出响应，把文件 index.htm 发给浏览器。
(7) TCP 连接释放。
(8) 浏览器显示“清华大学院系设置”文件 index.htm 中的所有文本。

长连接和短连接

http://www.codeceo.com/article/http-long-connect.html
1. HTTP协议与TCP/IP协议的关系
HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。TCP有可靠，面向连接的特点。
2. 如何理解HTTP协议是无状态的

使用HTTP协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计的如此简单。
无状态-->导致网站无法保存用户的状态-->引入Cookie技术
有了Cookie再用HTTP协议通信，就可以管理状态了

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。
3. 什么是长连接、短连接？
在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议

http://www.cnblogs.com/yangbodong/p/4964698.html

图解HTTP读书笔记

特别全面！！！
https://segmentfault.com/a/1190000004869057
这个也还可以
https://mozillazg.com/2015/08/tujie-http-note.html