HTTP基础

DNS

DNS就像网上的电话簿，当你只知道某个网址的名字而不知道它的地址时，计算机帮助你做这一层映射。

当你访问 http://baidu.com 时, 你的电脑使用 DNS 检索网站的 IP 地址204.13.248.115。 如果没有 DNS, 你只能直接访问我们的网站(或任何网站) , 比如 http://204.13.248.115。

DNS 是如何工作的？

使用缓存。一开始当你要求计算机解析一个主机名, 例如访问 http://baidu.com。 你的电脑首先看到的是它的本地 DNS 缓存, 该缓存存储计算机最近检索到的信息。如果你的计算机还是不知道答案, 那就需要执行一个 DNS 查询来找出答案。

询问递归式 DNS 服务器。如果信息不存储在本地, 计算机联系您的 ISP（网络服务提供商） 的递归 DNS 服务器。 这些专用计算机为你执行一个DNS查询工作。 递归服务器有它们自己的缓存(第二级缓存)

询问根域名服务器。如果递归服务器没有答案, 他们就会查询根域名服务器。 根域名服务器是一种计算机，它可以回答相关域名的问题, 如 IP 地址。

询问 TLD 域名服务器。根域名服务器将查看请求的第一部分, 按从右到左的顺序，从www.baidu.com找到.com, 并将请求指向.com对应的顶级域服务器(TLD).com. 每个TLD, 例如.com，.org, .us，拥有自己的顶级域名服务器,

询问权威的 DNS 服务器。TLD域名服务器会继续检查请求的下一部分（dyn）www.dyn.com, 并将查询指向负责此特定域名的服务器。

找回记录。递归服务器从权威服务器中检索 baidu.com 的记录, 并将记录存储在本地缓存中。

ping

ping命令主要是用来检查路由是否能够到达，由于ping命令发送的数据包非常小，所以在网上传递的速度很快，可以快速地检测你要去的站点是否可以到达。

网络上的机器都有唯一确定的IP地址，我们给目标IP地址发送一个数据包，对方就要返回一个同样大小的数据包，根据返回的数据包我们可以确定目标主机的存在。

正向代理和反向代理

代理是一个中介。正向代理一般用于内网服务器对请求进行转发，访问外网服务器。反向代理用于将外网服务器的请求转发到内网服务器上。

事务

一个HTTP事务由一条（客户端发往服务器）的请求命令和一个（服务器发回客户端）的响应结果组成。

HTTP使用术语流入(inbound)和流出(outbound)来描述事务处理。

报文

HTTP报文是由一行行的键值对字符串组成的，HTTP报文都是纯文本，不是二进制代码，所以可以很方便进行读写。报文可以分为请求报文和响应报文。报文由三个部分组成，对报文进行描述的起始行(start line)，包含属性的首部(header)块，以及包含数据的主体(body)块。

起始行: HTTP/1.0 200 OK    //OK这里是解释性原因短语
首部: Content-type: text/plain
Content-length: 19
主体: message...

状态码

Status 1xx(临时响应) 表示临时响应并需要请求者继续操作

Status 2xx(成功)

Status 3xx(重定向) 一般用来重定向

Status 4xx(请求错误) 请求出错

Status 5xx(服务器错误)

状态码用来告知客户端请求状态，伴随着状态码，HTTP还会发送一条解释性的原因短语

接下来是几个常见的状态码，200就不说了。

301是永久性转移，响应的Location首部中应该包含资源现在所处的URL

302是暂时性转移，但是客户端应该使用Location首部给出的URL来临时定位资源，将来的请求仍应使用老的URL，301比302更有利于SEO。

304是上次请求后，使用缓存资源。(下面会详细讲到)如果在chrome devtools中发现某静态资源的状态码是304，需要强制刷新浏览器。401是请求需要身份验证。403服务器拒绝请求。

请求方法

请求方法不止是GET和POST，常用的还有PUT和DELETE，这四个请求方式分别对应查，改，增，删。

HEAD方法与GET方法的行为类似，但服务器在响应中只返回首部，不会返回主体部分。使用HEAD，可以查看响应中的状态码，看某个对象是否存在，通过查看首部，测试资源是否被修改。

客户端发起请求时，这个请求可能要穿过防火墙，代理，网关等其他应用程序，每个中间节点都可能修改原始的HTTP请求，TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成什么样子。TRACE请求会在目地服务器端发起一个“环回”诊断。形成最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文(以TRACE开头)。TRACE请求有其缺点，比如代理可能将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序(比如Web缓存)

OPTIONS方法请求Web服务器告知其支持的各种功能，可以询问服务器通常支持哪些方法

会话

http是无状态协议，那么它怎么保存用户的会话状态？首先会话状态是什么，打个比方，A和B隔着门聊天，这时C也在附近，A怎么确定和他说话的是B还是C，这就用到了会话，会话是A和B的聊天状态。B和A开始说话前，B把自己的贴身信物扔给了A，这个贴身信物是唯一，能确认是B的。这时A开启一次会话，并且把自己的话筒给了B，B拿着话筒就可以不断对A说话。因为C没有话筒，所以可以判断是谁在说话。等到B说完的时候，表明想关闭会话，那么A就知道B已经停止对他说话，把会话关闭，让B把话筒扔了。那么B扔的贴身信物就是我们平时常用的会员登录或者其他身份验证，B的浏览器发送了表明自己身份的请求，服务器知道这是用户B之后开启了一次session，并把这次会话也就是session的标识，通过cookie记录在B的浏览器上，每次B发送请求的时候带上了cookie，也就是拿着’话筒’说话。说完之后，B关闭浏览器，那么cookie消失，话筒没了，或者B选择登出，那么服务器A将cookie删掉，’话筒’也没了，会话都将结束。

那么没有cookie能不能进行会话呢，在用户B禁用了cookie之后，可以通过url记录会话信息，服务器通过改变B的url参数，使B的浏览器请求获得了’话筒’，这时候url就变成了这样: http ://www.xx.com？session_id = xx134x。

cookie

cookie在设置时需要在参数中指明过期时间，如果没指明，就没有过期时间。所以cookie的存储分为两种：1.持久cookie，数据保存在磁盘中 2.会话cookie, 数据保存在内存中，浏览器关闭后将被清除。上文中说到的cookie就属于第二种。

Expires与Cache-Control

Expires与Cache-Control就是服务器用来约定和客户端的缓存有效时间的。

Response-Headers
Cac
4000
he-Control: public, max-age=2600
Date: ...
Expires: Wed,29 Jan 2017 08:39:13 GMT

比如上面这个响应头，Expires（HTTP1.0）规定了缓存失效的时间，Date为当前时间，而Cache-control的max-age（HTTP1.1）规定了缓存有效时间(2600s)，唯一的区别是Expires要求客户端和服务器的时钟完全一致，而max-age则没有这个限制。 是在当前页面按下ctrl + r会默认跳过max-age和Expires的检验直接向服务器发送请求。和其他expire一样，可以将其设置为过去的一个时间来禁止缓存。

last-Modified/if-Modified-Since

在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间

Response Headers
Last-Modified：Wed,29 Jan 2017 08:39:13 GMT

当在缓存期内时，要通过按下ctrl + r会默认跳过max-age和Expires的检验直接向服务器发送请求。这时请求上会带有

Request Headers
If-Modified-Since: Wed,29 Jan 2017 08:39:13 GMT

这个值与上次相应中Last-Modified完全一致，服务器将这个数值与服务端最后修改时间对比，如果相同，则响应304，从缓存读数据，否则响应200，同时通过响应头更新Last-Modified的值

Etag/if-None-Match

Etag/if-None-Match和上面的方式一样，也要配合Cache-Control使用。实际上Etag不是文件的版本号，而是一串可以代表该文件唯一的字符串，（Apache中，ETag的值，默认是对文件的索引节，大小和最后修改时间得到的一个hash值）。对比Etag值的比对比时间戳的好处在于

1. 时间戳精确到秒，也许一秒内文件被修改了多次，而Etag唯一

2. 如果某些文件会定期生成，除了时间之外没有其他变化，但Last-Modified却改变了，导致文件无法使用缓存

3. 有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致的情况

不能缓存的请求

HTTP信息头包含Cache-Control：no-cache等等服务器告诉浏览器不用缓存的请求

需要根据Cookie，认证信息决定输入内容的动态请求不能被缓存

经过HTTPS安全加密的请求

POST请求无法被缓存

TCP连接和端口号

在TCP中，需要知道服务器的IP地址，以及服务器上运行特定软件的TCP端口号。

//使用了机器的IP地址 http://207.200.83.29:80/index.html http://www.netscape.com：80/index.html
//没有时默认80，https为443 http://www.netscape.com/index.html[/code] 
TCP连接是基于文本的

三次握手
TCP协议采用三次握手策略，发送端首先发送一个带SYN标志的数据包给对方，接收端收到后，回传一个带有SYN/ACK标志的数据包以传达确认信息，最后，发送端再回传一个ACK标志的数据包，代表握手结束。若在握手某个阶段中断，TCP协议会再次以相同顺序发送相同数据包。为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。断开一个TCP连接需要四次挥手(通过FIN包)

代理
代理位于客户端和服务器之间，接收所有客户端的HTTP请求，经过部分处理后转发给服务器。

Agent代理
用户Agent代理是代表用户发起HTTP请求的客户端程序，所有发布Web请求的应用程序都是HTTP Agent代理，Web浏览器就是一种Agent代理机制，除此之外还有爬虫等。

HTTPS更安全
因为网络请求需要中间有很多服务器路由器的转发，中间的节点都可能篡改信息，HTTPS之所以更安全，是因为它利用ssl/tls协议传输，保障了传输过程的安全性，加密原理请参考HTTPS为什么更安全

IE缓存问题
在IE8浏览器下，如果ajax请求的方法是GET，并且请求的URL不变，那么这个请求的结果就会被缓存。解决的方法是在URL加上时间戳参数等

图片缓存
当我们想在PC端用几个稍微大点的图片做动画，可以在网页create一个img节点，让这个img元素的src指向这些图片的地址。等到想使用这个图片的时候，浏览器中已经有对此路径的缓存了，这样就避免了页面卡顿。当然，如果用户设置了disable-cache，这个方法就失效了

TCP和UDP区别
TCP传输协议是基于连接的传输协议，也就是在正式发送数据之前，必须和对方通过三次握手建立可靠连接。

而UDP是面向非连接的协议，直接发数据包，只适用于一次传送少量数据，对可靠性要求不高的环境

输入一个URL之后
浏览器开启一个线程来处理请求，对URL分析判断如果是http/https协议就按照Web方式来处理

调用浏览器内核的对应方法，比如WebView中的loadUrl方法

通过DNS解析获取网址的IP地址，设置UA等信息发出第二个GET请求

客户端发送请求报头

服务器进行相应处理

处理响应报头，如果确定使用缓存，则返回304，没有的话返回200