tcp/ip 基础

2022/03/04 1015点热度 1人点赞 0条评论

这几天翻了下图解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已经放入百度云盘和阿里云盘,关注公众号,回复任意消息可获取链接。

公众号图片

yxkong

这个人很懒,什么都没留下

文章评论