TCP/IP协议分层
应用层
- TFP
- DNS
DNS域名解析的过程
在浏览器DNS缓存中搜索
读取系统的hosts文件,查找其中是否有对应的ip
向本地配置的首选DNS服务器发起域名解析请求
- HTTP
传输层
TCP(Transmission Control Protocel,传输控制协议)
1、建立连接三次握手
- 发送端首先发送一个带SYN(synchronize/'sɪŋkrənaɪz/同步 星课耐子)标志的数据包给接收方
- 接收方收到后,回传一个带有SYN/ACK(acknowledegment/ək'nɑlɪdʒmənt/确认回单)标志的数据包以示传达确认信息
- 最后发送方再回传一个带ACK标志的数据包,代表握手结束
- 在这过程中若出现问题中断,TCP会再次发送相同的数据包。建立之后开始数据通信。
问题1: 为什么不能是二次
三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的,三次通信是理论上的最小值。为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误,失效的连接请求:若客户端向服务端发送的连接请求丢失,客户端等待应答超时后就会再次发送连接请求,此时,上一个连接请求就是『失效的』,如果那个失效的连接请求抵达了服务端,由于只有两次握手,服务端收到请求就会进入接收状态,等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态,服务端将会一直等待下去,这样浪费服务端连接资源。三次就可以四次就浪费了资源。
2、断开的四次挥手
- 客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送
- 服务器B收到这个FIN,它发回一个ACK
- 服务器B关闭与客户端A的连接,发送一个FIN给客户端A
- 客户端A发回ACK报文确认
问题1: 为什么挥手需要四次
关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可能未必会马上会关闭连接,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
问题2:四次挥手释放连接时,等待2MSL的意义
为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失,因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段,而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认
UDP(用户数据协议)
问题1:TCP协议和UDP协议的区别是什么?
- TCP协议是有连接的,有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接,会话结束之后也要结束连接。而UDP是无连接的
- TCP协议保证数据按序发送,按序到达,提供超时重传来保证可靠性,但是UDP不保证按序到达,甚至不保证到达,只是努力交付,即便是按序发送的序列,也不保证按序送到。
- TCP协议所需资源多,TCP首部需20个字节(不算可选项),UDP首部字段只需8个字节。
- TCP有流量控制和拥塞控制,UDP没有,网络拥堵不会影响发送端的发送速率
- TCP是一对一的连接,而UDP则可以支持一对一,多对多,一对多的通信。
- TCP面向的是字节流的服务,UDP面向的是报文的服务。
网络层
在众多链路中,找到一条合适的传输路线,就是Ip
链路层
硬件上的范畴均在链路层上
发起HTTP请求
请求方法
- TRACE:追踪路径
- OPTIONS:询问支持的方法
- DELETE:删除
- HEAD:获取报文首部
- PUT:增
- POST:传输实体主体(改)
- GET:获取资源(查)
问题1:get和post方法有什么区别
- GET在浏览器回退时是无害的,而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark,而POST不可以。
- GET请求会被浏览器主动cache,而POST不会,除非手动设置。
- GET请求只能进行url编码,而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的,而POST么有。
- 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
- GET参数通过URL传递,POST放在Request body中
- 本质的区别:GET产生一个TCP数据包;POST产生两个TCP数据包
对于GET方式的请求,浏览器会把http header和data一并发送出去,
服务器响应200(返回数据);
而对于POST,浏览器先发送header,服务器响应100 continue,
浏览器再发送data,服务器响应200 ok(返回数据)
问题2:get为什么有长度限制?
- HTTP 协议 未规定 GET 和POST的长度限制
- GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度
- 不同的浏览器和WEB服务器,限制的最大长度不一样
- 要支持IE,则最大长度为2083byte,若只支持Chrome,则最大长度 8182byte
状态码
1**:信息性状态码
2**:成功状态码
200:OK 请求正常处理
204:No Content请求处理成功,但没有资源可返回 form提交,之后不跳转
206:Partial Content对资源的某一部分的请求 文件大,分段请求的情况
3**:重定向状态码
301:Moved Permanently 永久重定向 从响应头的location中取重定向地址
302:Found 临时性重定向
303:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,
能通过GET方法重定向到另一个URI上
304:Not Modified 缓存中读取
307:临时重定向,与302类似,只是强制要求使用POST方法
4**:客户端错误状态码
400:Bad Request 请求报文中存在语法错误
401:Unauthorized需要有通过Http认证的认证信息
403:Forbidden访问被拒绝
404:Not Found无法找到请求资源
5**:服务器错误状态码
500:Internal Server Error 服务器端在执行时发生错误
502:对用户访问请求的响应超时造成的
503:Service Unavailable 服务器处于超负载或者正在进行停机维护
HTTP请求报文与响应报文格式
请求报文包含四部分:
- a、请求行:包含请求方法、URI、HTTP版本信息
- b、请求首部字段
- c、请求内容实体
- d、一个空行
响应报文包含四部分:
- a、状态行:包含HTTP版本、状态码、状态码的原因短语
- d、一个空行
- c、响应内容实体
- b、响应首部字段
请求头
5A 5C D H 5I 2R U 20
Header | 解释 | 示例 |
---|---|---|
Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html,application/json |
Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
Connection | 表示是否需要持久连接。(HTTP 1.1默认进行持久连接) | Connection: close |
Cookie | HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
Content-Length | 请求的内容长度 | Content-Length: 348 |
Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
If-None-Match | 如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Range | 如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Range | 只请求实体的一部分,指定范围 | Range: bytes=500-999 |
Referer | 先前网页的地址,当前请求网页紧随其后,即来路 | Referer: www.zcmhi.com/archives... |
User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
响应头
3A 7C date 2 (E L S) 17
Header | 解释 | 示例 |
---|---|---|
Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
Age | 从原始服务器到代理缓存形成的估算时间(以秒计,非负) | Age: 12 |
Allow | 对某网络资源的有效的请求行为,不允许则返回405 | Allow: GET, HEAD |
Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
Content-Language | 响应体的语言 | Content-Language: en,zh |
Content-Length | 响应体的长度 | Content-Length: 348 |
Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: www.zcmhi.com/archives... |
Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
URL、URN、URI
- URL和URN都是URI的子集
- URL类似于住址,它告诉你一种寻找目标的方式
一个人的名字看作是URN;因此可以用URN来唯一标识一个实体
HTTPS
https其实就是在HTTP跟TCP中间加多了一层加密层TLS/SSL。
神马是TLS/SSL?
通俗的讲,TLS、SSL其实是类似的东西,SSL是个加密套件,负责对HTTP的数据进行加密。TLS是SSL的升级版。现在提到HTTPS,加密套件基本指的是TLS。
传输加密的流程
原先是应用层将数据直接给到TCP进行传输,现在改成应用层将数据给到TLS/SSL,将数据加密后,再给到TCP进行传输。
HTTPS是如何加密数据的
非对称加密 与 对称密钥 结合 利用非对称加密来传输对称密钥
公钥如何获取
CA(证书颁发机构)网站向CA提交了申请,CA审核通过后,将证书颁发给网站,用户访问网站的时候,网站将证书给到用户
数据传输仅单向安全
HTTPS虽然用到了公开密钥加密,但同时也结合了其他手段,如对称加密,来确保授权、加密传输的效率、安全性。
概括来说,整个简化的加密通信的流程就是:
小明访问XX,XX将自己的证书给到小明(其实是给到浏览器,小明不会有感知)
浏览器从证书中拿到XX的公钥A
浏览器生成一个只有自己自己的对称密钥B,用公钥A加密,并传给XX(其实是有协商的过程,这里为了便于理解先简化)
XX通过私钥解密,拿到对称密钥B
浏览器、XX 之后的数据通信,都用密钥B进行加密
注意:对于每个访问XX的用户,生成的对称密钥B理论上来说都是不一样的。比如小明、小王、小光,可能生成的就是B1、B2、B3
证书的安全性怎么保证
数字签名、摘要是证书防伪非常关键的武器
HTTPS握手流程
- 网站是怎么把证书给到用户(浏览器)的
- 上面提到的对称密钥是怎么协商出来的
- 上面两个问题,其实就是HTTPS握手阶段要干的事情。HTTPS的数据传输流程整体上跟HTTP是类似的,同样包含两个阶段:
握手、数据传输。
握手:证书下发,密钥协商(这个阶段都是明文的)
数据传输:这个阶段才是加密的,用的就是握手阶段协商出来的对称密钥
http2
二进制协议
多路复用
HPACK 头部压缩
服务器推送