tcp/ip网络基础

Posted 2022-03-07 5ycode

这几天翻了下图解TCP/IP，把网络相关的知识整理下。

主要包含以下内容：

• 网络基础知识
• tcp/ip基础知识
• tcp与udp
• http版本演化
• http响应码
• https

OSI参考模型

虽然ISO指定了一个国际标准OSI，对通信系统进行标准化。但是这个标准并没有得到普及，不过它的参考模型却用在了网络协议的制定中。

举一个例子。

tcp/ip 基础知识

TCP与UDP

TCP与UDP最大的区别，TCP是有状态，UDP是无状态，TCP是高可靠性通信，UDP主要是及时通信。

这里主要介绍tcp，包括：

• 特点介绍
• 首部格式
• 三次握手
• 数据发送
  • 窗口控制
  • 流控制
  • 拥堵控制
  • TCP拥堵（有点重复)
• 四次挥手

TCP报文头格式：

说明：

• 源端口：source port，发送端口号：16位
• 目标端口：destination port，接收端口号：16位
• 序列号：seq ，发送数据的位置，每发送一次累加：32位
• 确认应答号：ack，下次应该接收到的数据序列号：32位
• 数据偏移：TCP传输的数据从哪个位置开始计算，4bit
• 控制位 8位，依次是
  • CWR
  • ECE，为1，将拥堵窗口缩小
  • URG，为1，表示包中有需要紧急处理的数据
  • ACK，为1，确认应答的字段有效，必须设置为1
  • PSH，为1，表示接收到的数据立即传给上层应用协议，为0时，先缓存
  • RST，为1，表示TCP连接出现异常，必须强制断开
  • SYN，为1，表示希望建立链接，握手完成置为0
  • FIN，为1，表示今后不会再有数据发送，希望断开连接
• 窗口大小：16位，用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小
• 紧急指针
• 选项：长度可变
• 校验和：checksum

TCP三次握手和四次挥手以及数据发送

三次握手过程：

• ①，客户端发送syn包（syn=x）到服务器
• 客户端进入SYN_SENT状态，等待确认
• 同时还会请求设置MSS为4000
• ②，服务器应答ACK=1（ack=x+1）
  • 发送一个SYN包（syn=y）和ACK包返回
  • 服务器进入SYN_RECV状态
  • 告诉客户端MSS为1000
• ③，客户端接收SYN+ACK包
  • ack=x+2
  • 客户端和服务端进入ESTABLISHED
  • tcp连接成功

四次挥手过程

• ①，客户端发出FIN，请求断开

  • FIN=1,seq=x
  • 客户端进入FIN-WAIT-1状态
  • 主动断开

• ②，服务端ACK

  • ACK=1,ack=x+1,seq=y
  • 服务端进入CLOSE-WAIT状态
  • 客户端接收到后进入FIN-WAIT-2状态

• 服务端把要发的数据都发给客户端

• ③，服务端FIN，请求断开

  • FIN=1,ACK=1,seq=z,ack=x+1
  • 服务端进入LAST-ACK状态

• ④，客户端ACK

  • 等待2*MSL（最长报文寿命）最长240秒后释放，可以调整
  • ACK=1,seq=x+1,ack=z+1
  • 服务端进入CLOSED立即释放
  • 客户端进入TIME-WAIT

数据发送

• 正常发送通过seq能保证顺序以及数据的完整性
• 通过窗口控制，可以提高吞吐量，窗口控制也会带出一个高速重发控制，而不是等待超时再重发；
• 流控制通过服务器的负荷情况，调节客户端的窗口大小；
• 拥塞控制，为防止客户端突然发送较大量的数据，导致网络瘫痪，通过慢启动来逐步调节拥堵窗口的大小

为什么建立连接是三次握手，而不是两次握手？

• ACK能保证客户端和服务端是对等的，确保两台机器都没问题，防止客户端确认后服务端超时或断开

为什么建立是三次握手，而断开链接是四次挥手？

• 客户端想断开，可能服务端还有要返回的数据处理，如此服务端还有机会把未处理完的数据返回；
• 服务端处理完了发送关闭请求，这个时候才关闭，三次握手解决不了问题；
• 关闭还有主动关闭，两次握手解决；
• 这些都是TCP可靠性的保障

大量TIME-WAIT导致链接不够用

• 当系统压力较大的时候，特别时候网关或者服务调用外部服务的时候,因为需要2MSL时长才会关闭（120秒内）；

• 可以通过调整系统参数解决，降低回收时间

http版本演化

目前市场上主流用的还是http1.1

0.9版本

• 只有get，返回只能是html

1.0

• 新增post和head
• 一次请求就关闭
• 可以自定义context-type

1.1

• 新增put、patch、options、delete
• 引入持久链接（默认不关闭，可被复用）
• 支持断点续传
• 支持host与range头域（缓存的处理）
  未解决问题
• 明文传输
• header头部数据太长
• 每次传输需要重新连接
• server端不能主动push

2.0

• 是https协议的升级版

特点：

• 头信息和数据体都是二进制
• 复用tcp连接（netty的长链接）
• 引入头部压缩机制(grpc做固定映射，前后持有一个映射表)
• 允许主动push

https

基于http加了一层ssl/tls层。

为什么要加密？

• http明文传输不安全
• 经过中间代理服务器、路由器、wifi等容易被劫持
  • 轻则挂广告，挂马
  • 重则用户信息泄露
• 中间人攻击
  • 可以劫持服务端信息，替换公钥，然后给客户端
  • 之后劫持客户端信息，用自己的私钥解密，再用服务端的公钥加密

https通过CA机构颁发CA证书来完成加解密，流程

• 网站去ca机构申请数字证书
• ca证书内置持有者信息（域名）和公钥信息
• ca 机构会用自己的私钥将ca证书hash后，拿着hash结果生成一个数字签名，包括hash算法和签名信息
• 网站将证书内置到nginx或别的服务器里；
• 浏览器持有ca机构的公钥（ca对浏览器信任）
  • 从ca证书里获取明文信息、签名信息和hash算法
  • 通过内置的CA公钥对sign进行解密，得到散列值x1
  • 再用证书里的hash算法对明文信息进行hash，得到x2
  • x1=x2说明没有被篡改
• 中间人
  • 篡改证书？
    • 即使拿到ca的公钥，只能解密，没有ca私钥，无法再加密
  • 证书掉包？
    • 浏览器会校验证书的归属，请求的host如果不是原来的，就无法通过

常见http状态码

2xx 表示操作成功了

• 200 请求成功
• 201 请求被创建成功
• 202 请求已被接收，但未处理完（异步处理）

3xx 重定向

• 300 表示客户端需要做些额外的操作才能得到对应的资源
• 301 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
• 302 请求资源临时转移到新url，客户端继续用原来的
• 303 请求已被处理，不会再返回对应的内容（直接返回之前的url）
• 304 未修改。表示页面有缓存的情况下，缓存可用
  • css和图片服务器会自动完成last modifiled和if modified since
  • 对于动态页面，我们要在Response的header中添加Last Modified 定义，如果有效，就返回304，不用再返回实际内容，减少服务器压力；

4xx：客户端错误

• 400 客户端请求的语法错误，服务器无法理解
• 401 请求要求用户的身份认证
• 403 请求的资源被禁止访问或拒绝执行
• 404 服务器无法找到请求的资源
• 405 请求中指定的方法不允许

5xx 服务端错误

• 500 通用的服务器错误响应
• 501 服务器不支持请求的功能
• 502 网关错误（上游收到一个无效的响应）
• 503 服务器当前不可用
• 504 网关超时
• 505 不支持请求中指明的http协议版本

xmind已经放入百度云盘和阿里云盘，关注公众号，回复任意消息可获取链接。