输入URL，客户端到服务器通信全过程
按五层网络协议进行理解：
在主机上：
1、第五层——应用层：DNS解析
2、第四层——传输层：TCP三次握手、四次挥手
3、第三层——网络层：IP层
4、第2.5层——ARP地址解析协议（负责IP地址到MAC地址的解析）
5、第二层——数据链路层：MAC转发
6、第一层：物理层：把比特流转换为电信号
在路由器中进行转发：
1、解包目的MAC地址是否本路由，不是就丢弃
2、目的MAC是自己，解包，看目的IP是否是自己，是处理
3、目的IP不是自己，按路由表查询MAC地址
4、根据MAC表进行转发
到达服务器后：
解包，获取信息，通过三次握手于客户端建立TCP连接
备注：Http和Https的通信过程区别
DNS域名服务（应用层）
首先，客户端根据web域名，完成DNS解析
-
查询DNS缓存，看是否有记录；
-
查询本地hosts文件，看是否有记录；
-
查询本地DNS服务器，看是否有记录；
-
一路查询直到根域名服务器，根域名开始递归查询；
-
例如www.baidu.com，根域名服务器转到.com.域名服务器;
-
.com.域名服务器转到baidu.com.权威域名服务器；
-
baidu.com.域名服务器作为权威域名服务器，找到www的主机名，返回ip地址。
传输层（TCP）
三次握手
-
TCP客户端发送SYN=1，seq=x的同步包给服务器；
-
服务器收到后，发送SYN=1，ACK=1，seq=y，ack=x+1；
-
客户端收到后，发送ACK=1，seq=x+1，ack=y+1；
-
可以两次握手，第3次握手时，客户端可以发送想要发的数据
-
三次握手中，第一次服务器确定自己可以收，第二次客户端确定自己收发正常，第三次服务器确定自己发正常
-
如果没有第三次握手，服务器无法确认客户端是否建立连接，比如客户端此时撤销连接，但服务器却一直保持连接，就会造成服务器资源浪费
-
四次挥手
-
TCP客户端发送FIN=1，seq=x的包给服务器；
-
服务器收到后，发送ACK=1，seq=y，akc=x+1的；
-
此时服务器继续发送未发送完的消息，或接受未接收完的消息，等到服务器完成工作，发送FIN=1，ACK=1，seq=w，ack=x+1；
-
客户端收到后，发送ACK=1，seq=x+1，ack=w+1，并等待2个MSL（最长报文段寿命）。
-
如果没有第4次握手，服务器直接关闭连接，不管客户端是否收到FIN包，那么假设客户端未收到FIN包，就会一直重发FIN包，而不断开连接
-
等待2个MSL是为了确保服务器收到客户端的ACK包，如果服务器未收到ACK包，那么会重传FIN+ACK包，客户端就能在2MSL时间内收到，并重发ACK包
-
可以三次挥手，存在延时确认机制允许服务器可以过一会在发送ACK包，（Windows延迟200ms），如果服务器没有数据再发送给客户端，那就可以和FIN包一起发送（2、3步一起）
-
重传机制
-
超时重传（RTO，Rrtransmission Timeout ）：数据包丢失、确认应答丢失
-
RTT（Round-Trip Time）：往返时延，表示网络中两个主机之间的通信一来一回的时间间隔
-
RTO略大于RTT，如果RTO源大于RTT，就会导致网络效率低，反之，会一直被认为超时并重传
-
超时重传的数据再次超时的话，RTO扩大两倍，两次都超时重传，说明网络差，不宜传输数据
-
-
快速重传（Fast Retansmit）：
-
三次收到ack=x，就认为x丢失，于是重传x
-
比如1,2,3,4,5，服务器收到1，3，4，5，发送3次ack=2，客户端重传2，此时服务器返回ack=6（因为1,2,3,4,5都收到了）
-
滑动窗口
-
发送窗口
可用窗口大小=SND.WND-(SND.NXT-SND.UNA)
-
接收窗口
-
发送窗口中的可用窗口=发送窗口-已发送未确认的窗口大小
流量控制
-
发送方根据接收方的实际接受能力，来控制发送的数据量
-
当接受方的接受窗口为0时，会进行窗口关闭，并通过ACK包告知发送方，发送方会启动持续计时器，到时间就发送窗口探测报文，接收方给出自己当前窗口大小，如果还是0，发送方重复即使，一般是3次，三次后发送方发送rst包（reset）连接
-
糊涂窗口综合征：发送数据量很小的包，数据量小于IP头部+TCP头部40字节
-
接收方不发送小窗口大小给发送方
-
发送方避免发送小数据量的包
-
拥塞控制
-
拥塞窗口：发送方动态调节发送数据量大小
-
发送窗口=min（接收窗口，拥塞窗口）
-
当网络出现超时重传，就认为出现拥塞，拥塞窗口减小，没有拥塞，拥塞窗口增大
-
慢启动
-
窗口初始值为cwnd=1，门限为ssthresh
-
指数级增长：2，4，8。。
-
当窗口到达门限（cwnd=ssthresh），进入拥塞避免
-
-
拥塞避免（ssthresh默认一般为65535字节）
-
到达门限后，变为线性增长：+1，+1，+1。。
-
直到遇到拥塞，进入拥塞发生
-
-
拥塞发生：出现拥塞就会利用前面提到的两种重传机制
-
超时重传
-
门限变为拥塞窗口二分之一（ssthresh=cwnd/2）
-
拥塞窗口变为1（cwnd=1）
-
重新进入慢启动
-
-
快速重传（和快速恢复一起使用）
-
拥塞窗口和门限都变为当前拥塞窗口的二分之一（cwnd=ssthresh=old_cwnd/2）
-
进入快速恢复
-
-
-
快速恢复
-
拥塞窗口+3（cwnd=ssthressh+3）：因为收到3个ACK包
-
也就是快恢复实际是从old_cwnd/2+3开始，因为达到ssthresh，所以直接进入拥塞避免
-
分包和粘包
-
分包：有MSS最大消息长度限制应用层数据大于MSS，就要分包
-
粘包：TCP为了提高网络利用率，用Nagle算法，当要发送的数据量很小，就延迟发送，和下一个包一起发送
网络层（IP）
-
封装IP数据包
2.5层——ARP地址解析协议
-
利用ARP协议，解析MAC地址
-
在ARP缓存表查找目的IP，找到MAC地址；
-
当目的IP地址对应的MAC地址未知时，发送ARP数据帧，把以太网目的MAC地址设为全00：00：00：00：00：00，数据链路层封装MAC帧，将目的MAC地址设置为FF:FF:FF:FF:FF:FF，从除了该端口的其他端口广播，通过网络中的路由器（也有ARP协议）
-
其他主机收到该广播帧，发现ARP的目的MAC地址不是自己，丢弃
-
直到找到以太网目的IP对应MAC地址的主机，该主机记录源IP和源MAC地址到ARP缓存表，并返回响应
-
客户端获得目的MAC地址（过程中其他没有该MAC地址的路由器也要记录该IP和MAC地址）
-
数据链路层（MAC）
-
ARP地址解析得到目的MAC后
-
根据MAC地址表查找对应接口，找到目的MAC地址对应接口，进行转发
-
未找到目的MAC地址对应接口，目的MAC设为FF:FF:FF:FF:FF:FF，从其他所有接口进行广播
路由器（MAC帧离开客户端在网络中进行传输）
路由器集成交换机的功能
-
首先路由器拿到MAC帧，去掉头部8个字节（前同步码和真开始界定符），检查尾部FCS，不正确，丢弃该帧
-
目的MAC地址不是自己，丢弃
-
是自己，拆开，到IP包
-
目的IP是自己，接收
-
把源IP和子网掩码，接口或上一跳IP进行记录进路由表（表示到达上一个路由器的路由信息）
-
目的IP不是自己，查找路由表（目的IP与路由表中的子网掩码做and，看所得网络号是否有记录）
-
一条一条查找，找到网络号，从相对应的接口或者下一跳ip地址进行转发
-
没有找到，从记录的默认路由的端口或吓一跳IP地址进行转发（默认路由IP 0.0.0.0，子网掩码 0.0.0.0）
-
封装为MAC帧，目的MAC根据ARP协议找到下一跳路由器的MAC地址，并进行转发
-
直到到达目的MAC地址（也就是服务器）
-
物理层
-
把MAC帧变成二进制比特流，并转换为电信号， 在物理链路传输
Http和Https
Http过程
-
DNS解析域名，得到IP
-
ARP协议解析目的MAC地址
-
客户端与服务器三次握手建立TCP连接
-
客户端发送Http请求，服务器返回响应
-
客户端接受响应，在浏览器进行渲染
-
四次挥手终止TCP连接
Https通信过程（443端口）
-
SSL用来数字签名和认证，并产生对称密钥K
-
TSL利用对称密钥K进行数据传输
-
DNS解析域名，得到IP
-
ARP协议解析目的MAC地址
-
客户端与服务器三次握手建立TCP连接
-
客户端在TCP第三次握手或者重新发送给服务器的报文中，包含自己支持的SSL加密算法，TSL/SSL版本等列表和第一个随机数R1
-
服务器会在之前，向CA数字认证中心申请证书，CA用自己的私钥加密，并发送给服务器
-
服务器返回响应，报文包含选中的SSL加密算法，第二个随机数R2
-
服务器再次发送给客户端两个报文，一个包含自己的证书信息，一个包含自己的公钥（如果需要客户端的证书，也包含在第二个报文中，在网银登录时需要）
-
客户端通过CA的公钥验证证书的数字签名，通过就信任服务器
-
客户端生成第三个随机数R3，并利用R1,R2,R3生成对称密钥K这个K用于TSL协议）
-
用服务器的公钥加密第三个随机数R3（预主密钥），并发送给服务器
-
服务器用私钥解密R3，并利用R1,R2,R3，以和客户端同样的算法生成对称密钥K（这个K用于TSL协议）
-
客户端和服务器通过密钥K利用TSL协议进行数据传输
-
四次挥手
Get和Post
-
并非所有浏览器在POST中会发送两次TCP包，FireFox就只有一次
| Get | Post |
|---|---|
| 一个TCP数据包，浏览器把Http的header和data一起发送出去，因为不涉及body | 产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器发送body，服务器响应200 OK |
| 参数在URL中 | 参数在body中 |
| URL可见，如果用于传递用户名密码不安全，且能被浏览器缓存，查询历史纪录可查到 | 参数在body中，用户不可见，不能保存书签，查询历史纪录看不到 |
| URL长度收到浏览器服务器限制 | body长度理论上无限制，可以更长 |
| URL支持部分ASCII编码，比如不支持空格，需要被替换为%20等，对中文的支持可能乱码 | 支持多种编码，可以支持中文 |
| 会被浏览器缓存，可以保存为书签 | 不能保存为书签 |
| 用在服务器上获取数据 | 向服务器提交表单数据 |
| 状态码 | 描述 |
|---|---|
| 1XX | 提示信息，请求已接收，继续处理 |
| 2XX | 成功 |
| 3XX | 重定向 |
| 4XX | 客户端错误（语法错误或请求无法实现） |
| 5XX | 服务器错误（服务器不能返回响应） |
| 200 | OK |
| 204 | 请求被处理但没有资源可以返回 |
| 301 | 永久重定向（返回301，加新地址 ，浏览器显示就地址，但加载新地址的资源） |
| 302 | 临时重定向 |
| 400 | 语法错误，服务器无法识别 |
| 401 | 未认证 |
| 403 | 请求的资源禁止访问 |
| 404 | 服务器找不到资源 |
| 405 | 方法不被允许 |
| 500 | 服务器内部错误 |
| 503 | 服务器正忙，无法处理请求 |
| 504 | 网关超时 |
Http优化
-
TCP复用（Http1.1支持）：把多个Http请求复用到一个Http连接上
-
Http复用（负载均衡设备支持）：一个客户端的多个Http请求通过一个TCP连接处理，客户端连接负载均衡设备，负载均衡设备与服务器连接，放客户端完成一次Http请求，断开与负载均衡设备连接，但负载均衡折别与服务器保持连接，下一次客户端在于负载均衡设备建立连接即可，使得服务器不用一直断开，节约资源
可断开
一直保持
客户端浏览器
负载均衡设备
服务器1
-
内容缓存：常用内容且无需经常更新，缓存到浏览器
-
压缩：将文本数据压缩
Http和Websocket
-
Http中，客户端主动，服务器被动，有长连接和短连接：
-
长连接一段时间保持TCP连接
-
短连接每次发送一次请求获得响应都要建立TCP握手三次
-
-
Websocket客户端服务器双工：
-
服务器可以在没有请求的情况下向客户端发送消息
-
服务器和客户端交换的header很小，可以节约资源
-
-
Http长连接每次都要发送header，Websocket只需要一个request和response
Cookie和Session、JWT
Cookie
-
会话跟踪技术，服务器生成，保存在浏览器本地，存储键值对，默认浏览器关闭过期
-
客户端与服务器建立TCP连接，第一次请求时，服务器生成cookie，（可以选择时/否保存在服务器），发送给浏览器
-
浏览器每次发送请求都带上cookie信息
-
应用场景：
-
保持登录状态
-
获取用户名，在浏览器显示
-
Session
-
服务器会话跟踪技术，服务器生成，保存在服务器，存储键值对，默认两周过期
-
依赖cookie，唯一标识码session id存储在cookie中
-
base64加密
-
应用场景：
-
安全性比较高的数据，银行卡账户密码等
-
也可以保持登录：sessionid给用户，用户保存cookie到本地，下次在启动浏览器，发送这个cookie中的sessionid个i服务器，服务器调出session信息即可
-
-
实现方法：
-
浏览器不禁止cookie，且保存cookie
-
浏览器禁止cookie，保存sessionid后，提出sessionid但是通过url或者提交表单隐藏字段的方式
-
JWT（Json Web Token）
-
组成：
-
Header：通常包含两个字段
{ "alg": "HS256" # 默认HMacSha256 "typ": "JWT" # 默认JWT }-
Playload：一个json字符串，包含用户信息、过期时间等
{ # 公有声明 "exp": xxx # 过期时间 "iss":xxx, # (issuer) 指明此token的签发者 "aud":xxx, # (Audience) 指明此token的签发群体 "iat":xxx, # (ISSued At) 指明此创建时间的时间戳 # 私有声明 "username": "aaa" # 不能包含用户密码等，因为可以被base64解码 }-
Signature：签名
HMACSHA256(base64.b64encode(Header.encode())+'.'.encode()+base64.b64encode(Playload.encode()),Secret_key)
-
-
JWT认证过程
-
客户端通过POST表单提交用户名、密码
-
服务器验证成功，将用户id和其他信息作为JWT Playload（负载），与JWT Header分别进行base64编码后，进行签名，生成一个JWT字符串xxx.yyy.zzz（三部分）token，返回给客户端，在Playload中有过期时间
-
客户端保存token，并设置有效期（建议和服务器一致），可以保存在cookie，也可以保存在内存（移动端没有cookie或者浏览器不允许cookie时）
-
客户端每次发送请求给服务器，都会把这个token放在Http或Https的header的Authorization位置
-
服务器检查token是否是发给自己的，是否在有效期，签名是否正确，都满足条件，返回正常响应，否则，返回登陆错误并跳转到登录页面
-
token有效期：有效期有服务器设置，有效期更新：
-
浏览器每次发送请求，服务器都重新生成token
-
服务器检查token，小于阈值（还没过期），就重新生成
-
| session | JWT |
|---|---|
| 保存在服务器 | 保存在客户端 |
| 如果session包含许多信息，增加服务器存储压力 | 签名的计算和验证花费服务器计算时间 |
区别
| cookie | session | JWT |
|---|---|---|
| 客户端 | 服务器中 | 客户端 |
| 不安全，可以分析本地cookie | 在服务器中，比较安全，且用base64加密 | 有签名技术，防止篡改 |
| 客户端本地存储，不安全 | 依赖cookie，唯一标识session ID在cookie中，有存储压力 | 不依赖cookie和session，服务器只需要计算签名正确性，没有存储压力 |
| 默认浏览器关闭过期 | 默认两周过期 | 有设置的过期时间 |
3064
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
