从输入url到页面（二）：TCP/IP 与 http协议

4、TCP/IP协议

　　拿到域名对应的IP地址以后，浏览器会以一个随机端口（1024<端口<65535）向服务器的WEB程序发起TCP的链接请求。这个链接请求到达服务器端后（这中间经过各类路由设,代理，局域网内除外），进入到网卡，而后是进入到内核的TCP/IP协议栈（用于识别该链接请求，解封包），最终到达WEB程序，最终创建了TCP/IP的链接。能够保证传输的报文永不丢失，受损或者乱序

（一）IP数据包

　　TCP的数据，是经过名为IP分组的小数据块来发送的。以流的形式将报文数据的内容，经过一条打开的TCP链接按序传输。TCP收到数据流以后，将数据流砍成小TCP数据段，并将其封装在IP分组中，经过网络进行传输。

　　每一个IP分组包括：IP分组首部，TCP段首部，TCP数据块

　　IP分组首部包含了源和目的IP地址、首部长度、数据报总长、首部较验和等标记。

　　TCP段的首部包含了TCP端口号、TCP控制标记、和用于数据排序和数据完整性检查的一些标记。

（二）TCP链接

　　任意时刻计算机均可以有几条TCP链接处于打开状态，是经过端口号来保持全部的这些链接持续不断地运行的。

　　经过四个值来识别和惟一地定义一条链接：<源IP，源端口号，目的IP，目的端口号>。两条不一样链接不能拥有4个彻底相同的地址组件值。

（三）HTPP事务的时延

　　一、  若是对URI的主机名最近没有访问，经过DNS解析须要花费时间

　　二、  TCP链接创建时延。三次握手，多条链接的时延会快速的叠加。

　　三、  传输请求报文，服务器接收并进行处理。

　　四、  服务器会送HTTP响应报文。

（四）TCP性能聚焦

　　影响较大，较常见的TCP相关时延包括：创建握手；慢启动拥塞控制、数据汇集的Nagle算法、用于捎带确认的TCP延迟确认算法、TIME_WAIT时延和端口耗尽。

　　一、  在创建一条新的链接以前，甚至在发送任意数据以前，TCP软件之间会交换一系列的IP分组，对链接的有关参数进行确认。若是链接只用来传送少许数据，这些交换过程会严重下降HTTP的性能。

　　　　第一步，客户端向服务器发送一个小的TCP分组，其中设置一个特殊的SYN标记，说明是一个链接请求。

　　　　第二步，服务器若是接受了请求，对一些链接参数进行计算，向客户端回送一个TCP分组，分组中SYN和ACK标记都被置位，说明链接请求已被接受。

　　　　第三步，客户端回送一条确认信息，通知链接已经成功创建。现代TCP栈都容许客户端在这个分组中发送数据。304 Not Modified 等小型http事务，在创建链接上耗时可能50%以上。

　　二、  延迟确认。因特网没法确保可靠的分组传输，TCP实现有本身的确认机制来确保数据的成功传输。

　　　　每一个TCP段都有一个序列号和数据完整性校验和。接收者收到无缺的段时，都会向发送者回送小的确认分组。若是发送者没有在指定的窗口时间内收到确认信息，发送者就认为分组已经被破坏，并重发数据。

　　　　因为确认报文很小，因此TCP容许在发往相同方向的输出数据分组中对其进行“捎带”。不少TCP栈都实现了一种“延迟确认”算法。会在一个特定的窗口时间内，将输出确认存放在缓冲区内，以寻找可以捎带它的输出数据分组。若是没有输出数据分组，就将其单独发送。

　　　　可是，HTTP具备双峰特征的请求，应答行为下降了捎带信息的可能。一般，延迟确认算法会引入至关大的时延。根据所使用操做系统的不一样，能够调整或禁止延迟确认算法。

　　三、  TCP慢启动。链接会随着时间进行自我“调谐”，起初会限制链接的最大速度，若是数据传输成功，会随着时间的推移提升传输的速度。用于阻止因特网的忽然过载和拥塞。

　　　　因为这种特性，新打开的链接传输速度会比交换过必定数量数据的链接慢一点。应尽可能重用现存链接。

　　四、  Nagle算法与TCP_NODELAY。TCP有一个数据流接口。能够将任意大小的数据放入TCP栈中，因此若是大量包含极少数据的分组，网络的性能就会严重降低。

　　　　Nagle算法试图在发送一个分组以前，将大量TCP数据绑定在一块儿，提升网络效率。鼓励发送全尺寸的段（LAN上最大尺寸的分组大约是1500字节，在网络中是几百字节）。只有当全部其余分组都被确认以后，Nagle算法才容许发送非全尺寸的分组。

　　　　HTTP应用程序经常会在本身的栈中设置参数TCP_NODELAY，禁用此算法，提升性能。

　　五、  TIME_WAIT累积与端口耗尽

　　　　端口耗满是很严重的问题，当某个TCP端点关闭链接时，会在内存中维护一个小的控制块，用来记录最近所关闭链接的IP地址和端口号。

　　　　一般只会维持一小段时间，2分钟左右，以确保在这段时间内不会建立具备相同地址和端口号的新链接。防止来自以前链接的复制分组插入了具备相同链接值的新TCP流中，会破坏TPC数据。

（五）HTTP链接的处理

　　　若是只对链接作简单的串行管理，TCP的链接时延和慢启动会很快叠加起来。更坏的状况，有些浏览器在对象加载完毕以前没法获知对象的尺寸，计算布局位置，在加载完以前，页面没法显示内容。几种现存和新兴的方法能够提升HTTP的链接性能。

　　一、  并行链接。浏览器能够执行多个HTTP事务。

　　　　优点：使链接时延重叠，高效利用带宽，多个组件对象同时显示加载对用户友好。劣势：带宽有限时，每一个链接都很慢尤为新打开时，web服务器的性能压力

　　　　现状：浏览器使用了并行链接，对同一域名的连接总数限制为一个较小的值，且服务器能够随意关闭超量链接。

　　二、  持久连接。HTTP/1.1容许设备在事务处理结束以后将TCP链接保持在打开状态。

　　　　优点：避免屡次的链接时延，和慢启动的拥塞适应，减小了链接数量、性能压力。

　　　　劣势：按顺序串行请求，对带宽可能有浪费。

　　　　现状：与并行链接结合使用，打开最多两条并行的持久链接。

　　三、  管道化连接。在持久链接的基础上的优化。

　　　　在响应到达以前，能够将多条请求放入队列，顺序发出。

　　　　限制：服务器必须按照与请求相同的顺序回送HTTP响应。链接会在任意时刻断开，客户端要能重发全部未完的请求。不该该在管道中发送有反作用非幂等的请求（post等），没法安全的重试。

　　四、  SPDY会话层协议。Chromium引入的新机制，为了解决网络延迟和安全性问题。

　　　　在HTTP2.0的草案中将引入此协议。核心思想是多路复用，使用一个链接来传输网页中的众多资源。HTTP>SYDY>SSL>TCP>IP。

　　　　优点：根据请求的优先级，服务器能够优先回复优先的资源。服务器能够在发送网页时，尝试发送一些信息给浏览器，浏览器能够提早知道并决定是否须要下载，甚至，服务求能够主动发送资源。

5、HTTP报文

　　报文由三部分组成：起始行，首部块，可选包含数据的主体。分为请求报文和响应报文。

　　请求报文：

<method> <request-URL> <version>
<header>

<entity-body>

　　响应报文：

<version> <status> <reason-phrase>
<headers>

<entity-body>

（一）请求报文

　　在请求报文起始行开始位置，客户端但愿服务器对资源执行的动做标识。各方法在网络发送并没有实质不一样，都是HTTP的报文，只是在规范上有所不一样，如GET不发送实体，能够在URL后加查询字符串；POST将数据放在数据报文实体中。服务器端根据不一样的路由设置来处理对应的报文。

　　一、  GET方法。最经常使用的，安全方法，一般用于请求服务器发送某个资源。

　　二、  HEAD。只返回一样GET方法的首部信息。不会反悔实体的主体部分。能够用来查看对象资源的状态，是否存在，是否有效。

　　三、  PUT。向服务器写入文档，建立一个由所请求的URL命名的新文档。

　　四、  POST，起初是用来向服务器输入数据的，一般用来支持HTML的表单。

　　五、  TRACE，终端服务器会发起一个追踪响应，在主体中携带它收到的原始请求报文，能够查看报文是否被中间实体修改过。缺陷是,要假定中间应用程序对不一样类型的请求处理是相同的.

　　六、  OPTIONS,请求告知服务器对某资源支持的各类功能。

　　七、  DELETE，请求删除URL指定的资源。

（二）报文首部

　　

能够分为通用、请求、响应、实体、扩展首部。

一、  通用信息性首部

　　通用缓存首部

二、  请求首部

　　请求信息性首部，

　　Accept内容协商首部

　　条件请求首部

　　安全请求首部

　　代理请求首部

三、  响应首部

　　信息性首部

　　协商首部

　　安全响应首部

四、  实体信息性首部

　　内容首部

　　实体缓存首部

6、Web的结构组件

　　代理：接收客户端请求，转发给服务器。反向代理，负载均衡等应用。

　　缓存：或代理缓存。特殊的HTTP代理服务器，提供文档缓存服务。

　　网关：特殊上服务器，做为其余服务器的中间实体使用，用在HTTP协议与其余协议之间的转换沟通。

　　隧道：在链接之间对原始数据进行盲转发的HTTP应用程序。

　　Agent代理：浏览器，网络爬虫