博主只是记录一些不太容易记住的东西,不一定齐全,不一定符合大家的口味,如果有错的恳请看官指正,谢谢。
计网
tcp,udp区别
- TCP:提供的是面向连接、可靠的字节流传输,占用系统资源多,要维护连接,保证顺序
- UDP:面向数据报,不提供可靠性,响应快,轻量
tcp可靠传输
序列号,ACK(累计ack),重传(等待2RTT+偏差)
tcp窗口控制与重传
窗口内,可以不等ack一直发,发送端收到三次一样的ack会立刻重传ack后面的数据,应答丢失不重发,因为假如丢失了接收端会一直要数据。
tcp拥塞控制
- 慢启动:从1开始指数增大cwnd(拥塞窗口)大小
- 拥塞避免:慢启动达到阈值ssthresh开始线性增加窗口大小
- 乘法减小:网络出现超时,将cwnd置为1,ssthresh置为cwnd的一半,然后开始执行慢启动
- 快重传:接收者收到顺序出错的报文,立刻回复重复的ack提醒发送方立即重传
- 快恢复:超时时拥塞窗口不再从1开始慢启动,而是直接从1/2超时时窗口大小开始拥塞避免
tcp三次握手四次挥手,状态转移
三次握手:
- 发送方发送:SYN,seq=a,客户端进入SYN_SEND状态
- 接收方发送:SYN+ACK,seq=b,ack=a+1,服务器进入SYN_RECV状态
- 发送方发送:ACK,检查seq,客户端和服务器进入ESTABLISHED状态
- 为什么不两次握手?
保障双方都确认了初始seq,被动建立连接的一端也需要确认对方认可了他的序列号。 - 为什么不四次握手?
中间被动建立连接方发送的两个报文可以合并。
四次挥手:
- 主动关闭方发送FIN,状态变为FIN-WAIT-1
- 被动关闭方发送ACK,状态变为CLOSE_wait,主动方收到ACK变成FIN-wait2
- 被动关闭方发送完数据发送FIN,进入LAST-ACK
- 主动关闭方发送ACK ,等待2msl(报文段最大生存时间)然后关闭连接,TIME-WAIT状态,然后CLOSED。被动方收到以后CLOSED
- 为什么不挥手三次?
中间两次不能合并,防止有数据没发完 - 为什么要等2msl?
防止对端没收到ACK;保障双向传输中未接收到或迟到的报文段消失,不能保证下次通信客户端端口,如果冲突会导致新连接混乱。
滑动窗口,发送接收窗口
- 发送窗口大小取决于对方的接收窗口大小,和拥塞窗口大小的较小值
- 窗口满:发送端停止发送数据,等通知
- 发送端怎么知道窗口满了:接收端返回的ACK说窗口为0,Windows Full
- 发送端怎么知道可以发了:接收端返回ACK说窗口有了,Window Update
- 通知发送的包丢了怎么办:好问题,不知道,猜测是接收端没接收到数据重传通知包吧?
参考:
TCP滑动窗口(发送窗口和接受窗口)
关于TCP窗口大小的缩放
关于TCP Zero Window Update感知的非常棒的优化
TCP粘包,拆包
- 应用程序写入的数据大于套接字缓冲区大小,这将会发生拆包。
- 应用程序写入数据小于套接字缓冲区大小,网卡将应用多次写入的数据发送到网络上,这将会发生粘包。
- 进行 MSS (最大报文长度)大小的 TCP 分段,当 TCP 报文长度-TCP 头部长度>MSS 的时候将发生拆包。
- 接收方法不及时读取套接字缓冲区数据,这将发生粘包。
解决方案:消息格式定义:消息头标识长度;消息定长;消息边界等
负载均衡
BS,CS架构
CS:客户端-服务端模式,需要有客户端
BS:浏览器-服务端模式,浏览器的前端代码也来自于服务端
tcp连接复用
连接池,将前端大量客户的HTTP请求通过后端与服务器建立的少量TCP长连接来查询,减小服务器的性能负载,并发连接数,同时缩短通信延迟。
内容缓存
把一些经常被访问的资源存在负载均衡设备的内存中,如果该资源不失效,则负载均衡设备直接返回资源,不请求服务器。
TCP缓冲
解决客户前端网络速度和后端网络速率高延迟小的不平衡和阻塞问题。负载均衡设备收到服务器回复的数据后依次存放到缓冲区,再发送给客户。是L7应用负载均衡的核心。
http压缩
负载均衡设备去掉客户端的压缩标志转发给服务器,服务器返回内容后负载均衡设备做压缩返回给客户端
SSL加速
负载均衡设备做SSL处理,与客户端进行协商,对客户端的请求解密后发送给后端服务器,然后加密回复发送回客户端。
http与https
- http:明文传输,部署成本低资源占用低,默认端口80
- https:加密传输,安全性高,保证了传输安全,防止传输过程被监听、防止数据被窃取,可以确认网站的真实性,支持双向认证,建立连接过程长,需要握手,部署成本高,加解密占用资源多,默认端口443
http特性
- 长连接:1.1起支持长连接,即keep-alive,默认开启,TCP不断开可以复用
- 无状态:http协议本身不维护请求与响应之间的状态
http报文格式,头部内容
请求行,请求/响应头,通用头,实体头,实体
只常用
通用头
Cache-Control:缓存管理
Connection:连接状态管理,保持(keep-alive)
Date:日期时间
Upgrade:协议升级
请求头
method,uri,version
Host:主机名
Connection:通知连接状态
Cookie:客户端暂存的信息
Auth:http认证信息
DNT:禁止追踪
UA:客户端信息
Referer:从何跳转而来
Accept:客户端支持的数据格式
Acc-Encoding:客户端支持的压缩方法
Acc-Language:客户端支持的语言
响应头
version,status_code
Server:HTTP服务器信息
Expires:缓存时间
Last-Modified:最近修改时间
Location:告诉客户端请求哪
实体头
Allow:支持的HTTP方法
Content-xxx:实体相关的信息
http状态码
常见:
状态码 | 英文 | 含义 |
---|---|---|
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 | 永久移动。Location指向跳转资源。客户端可以对结果进行缓存,302必须请求原链接。 |
302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
303 | See Other | 查看其它地址。自动重定向到GET |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
307 | Temporary Redirect | 临时重定向。常用作chrome的HSTS重定向。302可能会把POST改成GET访问,307按原访问方式访问,不自动转换为GET |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
401 | Unauthorized | 请求要求用户的身份认证 |
402 | Payment Required | 保留,将来使用 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
405 | Method Not Allowed | 客户端请求中的方法被禁止 |
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协议的版本,无法完成处理 |
参考:
【一天一个知识点系列】- Http之状态码 非常生动形象
HTTP状态码 - 菜鸟教程
http2.0
HTTP1.1长连接,实现了管道传输,但是按顺序发的还是在队列中按顺序回复,可能出现队头阻塞。
2.0特点:
- 多路复用:可以并发请求回应,不会出现队头阻塞
- 二进制格式:以帧的形式存在,分为头信息帧和数据帧
- 服务端可以主动推送到客户端缓存;
- 头部压缩:客户端服务端同时维护头信息表,不发送一样的字段,HPACK
- 数据流:每个请求和回应的数据包对应一个Stream,有编号,还可以规定流的优先级,服务器优先响应
存在问题:多请求复用一个TCP连接,一旦发生丢包,就会阻塞住所有的 HTTP 请求。
http3.0
基于 UDP 的 QUIC 协议。
特点:QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响。
HTTPS 要建立一个连接,要花费 6 次交互,先是建立三次握手,然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次,减少了交互次数。
https加密的实现,TLS在哪一层
- 简单版本
客户端主动请求,服务端发送自己的证书,客户端对证书进行验证(使用预信任的根证书公钥验证证书签名),然后用证书公钥加密对称加密密钥发送给服务端,服务端用私钥解密以后使用该对称加密密钥通信。 - 复杂版本
C->S:Client Hello,时间戳,随机数,会话ID,支持的加密套件,扩展
S->C:Server Hello,时间戳,随机数,选定的套件,扩展
S->C:Certificate,服务端证书
S->C:Server Key Exchange,公钥密码服务端参数
S->C:Server Hello Done
C->S:Client Key Exchange,公钥密码客户端参数
C->S:Change Cipher Spec,确认修改加密方式
C->S:Encrypted Handshake Message
S->C:New Session Ticket
TLS,SSL,HTTPS,SSH辨析
- SSH其实是专门为shell设计的一种通信协议,它垮了两个网络层(传输层和应用层)。
- TLS(Transport Layer Security)相当于是SSL(Secure Sockets Layer)协议的一个后续版本,是SSL经过IETF标准化之后的产物。
- SSH通过人工鉴别Public Key的printfinger,或者手动添加公私密钥对,来判断与之通信的服务器是否可信。TLS引入了数字签名,证书。
- TLS获取服务端证书,证书中包含了CA的签名,如果用CA的公钥(预存储,预信任的)可以解密对比,确定证书是真的,服务端就可信。
- HTTPS(Hypertext Transfer Protocol Secure),也就是HTTP over TLS。用TLS来承载HTTP。
SSH连接过程
提供机密性,可靠性,完整性
S->C:Protocol,,Key Exchange Init
C->S:Protocol
C->S:Key Exchange Init
C->S:Elliptic Curve Diffie-Hellman Key Exchange Init
S->C:Elliptic Curve Diffie-Hellman Key Exchange Reply, New Keys
C->S:New Keys
证书包含的信息
颁发者,使用者,有效期
证书版本,序列号,签名算法,哈希算法,公钥
附加信息:用法等等。
openid协议
ipv6地址长度
ABC类地址,保留地址
网络号,主机号,掩码
token,session,cookie区别
- cookie数据存放在客户的浏览器上,用来保存用户信息
- session数据放在服务器上,服务器用于记录用户状态
- token,令牌,把信息做签名,生成token,验证token,用CPU计算代替session存储
session的实现一般依赖于cookie
cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,session在服务端,相对更安全
session会在一定时间内保存在服务器上。当访问增多,会比较占用服务器的性能
单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie
token优势在于无状态可扩展、
建议:将登陆信息等重要信息存放为SESSION;其他信息如果需要保留,可以放在COOKIE中。
dns查询
域名解析成ip地址
- 递归:DNS客户端到本地名称服务器,询问的DNS服务器代为查询并返回结果
- 迭代:本地名称服务器到其他名称服务器,查询由客户端自己从根服务器开始查询
浏览器输入url以后发生了什么
- 解析url,协议,域名,资源,看看是不是HTTPS
- DNS解析,获取IP
- 发包的时候要ARP,判断封包的MAC地址
- 网络层IP路由,路由表
- TCP连接建立
- HTTP请求发送
- 浏览器解析,渲染