一、请求报文和响应报文
http请求报文组成: 请求行+请求头+请求体
http响应报文组成: 响应行+响应头+响应体
请求行: 请求方法(HEAD/GET/POST) + 请求URL + HTTP协议版本
响应行: HTTP协议版本 + 状态码 + 状态码描述
请求头: 比如客户端的Cookie和User-Agent就放在这里
响应头: 比如服务器的Set-Cookie和Server信息就放在这里
请求体: 比如客户端POST的数据就放在这里(对比:GET的数据放在请求行的URL里)
响应体: 比如服务器返回的HTML和JSON数据就放在这里
二、输入地址到展示过程
（1）浏览器输入url,先解析url地址是否合法
（2）浏览器检查是否有缓存(浏览器缓存-系统缓存-路由器缓存)如果有,直接显示.如果没有,跳到第三步
（3）在发送http请求前,需要域名解析(DNS解析),解析获取对应过的ip地址
（4）浏览器向服务器发起tcp链接,与浏览器简历tcp三次握手
（5）握手成功后,浏览器向服务器发送http请求,请求数据包
（6）服务器收到处理的请求,将数据返回至浏览器
（7）浏览器收到http响应
（8）浏览器解析响应.如果响应可以缓存,则存入缓存
（9）浏览器发送请求获取嵌入在HTML中的资源(html,css,JavaScript,图片,音乐等),对于未知类型,会弹出对话框
（10）浏览器发送异步请求
（11）页面全部渲染结束
三、HTTP 请求方式/类型
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。向服务器读取数据，数据暴露在url中。 |
| 2 | HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
四、HTTP 状态码
下面是常见的HTTP状态码：
- 200 - 请求成功
- 301 - 资源（网页等）被永久转移到其它URL
- 404 - 请求的资源（网页等）不存在
- 500 - 内部服务器错误
HTTP状态码共分为5种类型：
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置”您所请求的资源无法找到”的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
五、HTTPS 和 SSL 加密
（1）http是直接和tcp通信,https=http+ssl加密
（2）https有ca证书,http一般没有
（3）http默认端口号为80,https默认端口号为443
（4）https基于传输层,http基于应用层
（5）https对于搜索引擎更友好,利于seo,百度,谷歌等搜索引擎优先索引https网页
ssl加密: 发送密文的一方使用对方的公钥进行加密处理”对称的密钥”,然后对方用自己的私钥解密拿到”对称的密钥”,这样可以确保交换的密钥是安全的前提下,使用对称加密方式进行通信。
所以,https采用对称加密和非对称加密两者并用的混合加密机制。
六、cookie 和 session
- cookies数据保存在客户端,session数据保存在服务端
- cookie可以减轻服务器压力但不是很安全,别人可以进行cookie欺骗,考虑到安全应当使用session
- session会在一定时间内保存在服务器上,当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie
- 单个的cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie
- 所以个人建议:
将登陆信息等重要信息存放为session;其他信息如果需要保留,可以放在cookie中
通过Web Server或者浏览器来获取Cookie.多数浏览器能够配置允许用户访问Cookies,但是不同站点之间的Cookie不能共享
cookie有一个属性expires,设置其值为一个时间,那么当到达此时间后,此cookie失效.通过Okhttp的拦截器去进行持久化cookie
七、HTTP 缓存机制
http缓存主要分为两种: 强缓存和协商缓存
a. 强缓存基本原理是: 所请求的数据在缓存数据库中尚未过期时,不与服务器进行交互,直接使用缓存数据库中的数据.
Expire指定了一个日期/时间,在这个日期/时间之后,http响应被认为是过时的.但是它本身是一个HTTP1.0标准下的字段,所以如果请求中还有一个置了"max-age"或者"s-max-age"指令的Cache-Control响应头,那么Expires 头就会被忽略.
Cache-Control通用消息头用于在http请求和响应中通过指定指令来实现缓存机制,其常用的几个取值有：
private: 客户端可以缓存
public: 客户端和代理服务器都可以缓存
max-age=xxx: 缓存的内容将在xxx 秒后失效
s-max-age=xxx: 同s-max-age,但仅适用于共享缓存(比如各个代理),并且私有缓存中忽略
no-cache: 需要使用协商缓存来验证缓存数据
no-store: 所有内容都不会缓存,强缓存和协商缓存都不会触发
must-revalidate: 缓存必须在使用之前验证旧资源的状态,并且不可使用过期资源
b. 当强缓存过期未命中或者响应报文Cache-Control中有must-revalidate标识必须每次请求验证资源的状态时,便使用协商缓存的方式去处理缓存文件
协商缓存主要原理是从缓存数据库中取出缓存的标识,然后向浏览器发送请求验证请求的数据是否已经更新,如果已更新则返回新的数据,若未更新则使用缓存数据库中的缓存数据
八、正/反向代理、中间人攻击
正向代理即是客户端代理,代理客户端,服务端不知道实际发起请求的客户端
反向代理即是服务端代理,代理服务端,客户端不知道实际提供服务的服务端
正向代理的用途:
（1）访问原来无法访问的资源,如google
（2）可以做缓存,加速访问资源
（3）对客户端访问授权,上网进行认证
（4）代理可以记录用户访问记录(上网行为管理),对外隐藏用户信息
反向代理的作用：
（1）保证内网的安全,阻止web攻击,大型网站,通常将反向代理作为公网访问地址,Web服务器是内网
（2）负载均衡,通过反向代理服务器来优化网站的负载
中间人攻击：
中间人攻击(Man-in-the-Middle Attack, MITM)是一种由来已久的网络入侵手段,并且当今仍然有着广泛的发展空间,如SMB会话劫持,DNS欺骗等攻击都是典型的MITM攻击.简而言之,所谓的MITM攻击就是通过拦截正常的网络通信数据,并进行数据篡改和嗅探,而通信的双方却毫不知情。
九、３次握手与４次挥手
3次握手,保障通讯双方有通信的基础;4次挥手,保障通讯双方可以安全的回收TCP通信的系统资源.HTTP是基于TCP的协议,TCP是可靠的传输层协议
具体内容:
三次握手: 是指在建立TCP连接协议时,需要在客户端和服务器之间发三个包,传送的包里不含数据,握手完毕后客户端和服务器才开始正式传送数据
第一次握手: 客户端发第一个包,SYN标志位为1,ACK=0,发送顺序号Seq=X(随机int).客户端进入SYN发送状态,等待服务器确认
第二次握手: 服务器收到包后发第二个包,包的SYN,ACK标志位=1,发送顺序号Seq=Y(随机int),接收顺序号ACK=X+1,此时服务器进入SYN接收状态
第三次握手: 客户端收到包后发第三个,SYN=0,ACK=1,接收顺序号ACK=Y+1,发送顺序号seq=X+1.客户端和服务器进入ESTABLISHED建立成功状态,完成三次握手
四次挥手: 是指终止TCP连接协议时,需要在客户端和服务器之间发送四个包
第一次挥手: 主动关闭方发送第一个包,其中FIN标志位为1,发送顺序号Seq=X
第二次挥手: 被动关闭方收到FIN包后发送第二个包,其中发送顺序号Seq=Z,接收顺序号ACK=X+1
第三次挥手: 被动关闭方再发送第三个包,其中FIN标志位为1,发送顺序号Seq=Y,接收顺序号ACK=X
第四次挥手: 主动关闭方发送第四个包,其中发送顺序号Seq=X,接收顺序号ACK=Y,完成四次挥手
TCP为什么是三次握手,而不是两次或四次?
TCP既要保证数据可靠传输,又要提高传输的效率,两次握手容易死锁,四次又浪费资源
TCP需要seq序列号做可靠重传或接收,防止连接复用时无法分辨seq是延迟的还是旧链接的,因此需要三次握手来确定双方的ISN(初始seq序列号）
比如一个seq过来了,跟现在记住的seq不一样,我不知道它是上条延迟的,还是上上条延迟的,所以接收方一定需要跟发送方确认SYN
为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
建立TCP连接时,ACK和SYN可以放在一个报文里发送.而关闭连接时,被动关闭方可能还需要发送一些数据后再发送FIN报文表示同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的
为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
无法保证最后发送的ACK报文会一定被对方收到,所以需要重发可能丢失的ACK报文
关闭连接后可能在相同的IP地址和端口建立新连接,为了防止旧连接的重复分组在新连接再现,2MSL足以让分组最多存活2msl秒被丢弃
十、其他
URI和URL
URI是统一资源标识符,而URL是统一资源定位符.每个URL都是URI,但不一定每个URI都是URL.这是因为URI还包括一个子类,即统一资源名称(URN),它命名资源但不指定如何定位资源
TCP和UDP
（1）TCP是面向连接的(在客户端和服务器之间传输数据之前要先建立连接),UDP是无连接的(发送数据之前不需要先建立连接)
（2）TCP提供可靠的服务(通过TCP传输的数据,无差错,不丢失,不重复,且按序到达);UDP提供面向事务的简单的不可靠的传输
（3）UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性比较高的通讯或广播通信.随着网速的提高,UDP使用越来越多
（4）每一条TCP连接只能是点到点的,UDP支持一对一,一对多和多对多的交互通信
（5）TCP对系统资源要求比较多,UDP对系统资源要求比较少
（6）UDP程序结构更加简单
（7）TCP是流模式,UDP是数据报模式
请求头内容
1）Accept 作用: 浏览器端可以接受的媒体类型 例: Accept: text/html
2）Accept-Encoding 作用: 浏览器申明自己接收的编码方法,通常指定压缩方法,是否支持压缩,支持什么压缩方法(gzip,deflate)
3）Accept-Language 作用: 浏览器申明自己接收的语言.例: Accept-Language: en-us
4）Connection 例如: Connection: keep-alive 当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接
5）Host(发送请求时,该报头域是必需的) 作用: 请求报头域主要用于指定被请求资源的Internet主机和端口号,它通常从HTTP URL中提取出来的
6）Referer 作用: 当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的
7）User-Agent 作用: 告诉HTTP服务器,客户端使用的操作系统和浏览器的名称和版本
浏览器f5和强制刷新ctrl+f5
- F5使用缓存,并且只有在资源内容发生变化的时候才会去更新资源.
当刷新一个页面的时,浏览器会尝试使用各种类型的缓存,并发送If-Modified-Since头到服务器,如果服务器返回304 Not Modified,那么浏览器会使用本地的缓存;如果服务器返回200 OK和资源内容,那么浏览器会使用返回的资源内容,并把资源内容进行缓存,待下次使用.
- CTRL-F5 强制更新页面资源的缓存
MSIE会发送Cache-Control: no-cache头,Firefox和Chrome除了发送Cache-Control: no-cache头之外,还会发送Pragma: no-cache头.Opera比较另类,不发送任何和缓存相关的头