计算机网络

session和cookies

详解

http1.0、http1.1、http2.0和http3

区别

  • http1.0 短连接,每个TCP连接只能发送一个请求
  • http1.1 是长连接,可以复用TCP连接,但是发送和接收严格有序
  • http2.0
    • 多路复用,随意发送帧,在接收方重新组成流
    • 头部压缩,利用索引值代替
    • 二进制帧,帧(标记属于哪个流)组成流
  • http3.0:http3

报文

通用头

  • GET /logo.gif HTTP/1.1
  • HTTP/1.1 200 OK

请求头

  • Accept:可以接收的文本类型
  • Connetion:HTTP连接类型
  • Cookie:
  • User-Agent:表示浏览器类型

响应头

  • Content-Type:返回文本类型
  • Date:服务器发送资源的时间
  • Connection:连接类型

BODY

  • 返回的内容

常见状态码

  • 1继续、2成功、3重定向、4客户端错误、5**服务器错误
  • 200:请求成功
  • 301:永久移动
  • 302:临实移动
  • 400:客户端请求语法错误
  • 404:服务器找不到资源
  • 500:服务器内部错误
  • 501:服务器不支持的功能

TCP和UDP

报文

TCP

  • 16位源端口号、16位目标端口号
  • 32位序号
  • 32位确认号

区别

  • TCP:有连接、面向字节流、可靠
  • UDP:无连接、面向数据报、不可靠

TCP重传机制

  • 没有收到ACK会重传数据
  • 超时重传:发送方始终未收到接收方第三个数据的ACK则重传
  • 快重传:如果,包没有连续到达,就ack最后那个可能被丢了的包,如果发送方连续收到3次相同的ack,就重传

TCP滑动窗口:控制发送方向接收方的发送速率

发送方的发送缓存内的数据都可以被分为4类:

  1. 已发送,已收到ACK
  2. 已发送,未收到ACK
  3. 未发送,但允许发送
  4. 未发送,但不允许发送
    其中类型2和3都属于发送窗口。
    接收方的缓存数据分为3类:
  5. 已接收
  6. 未接收但准备接收
  7. 未接收而且不准备接收
    其中类型2属于接收窗口。
  • 累计确认,不是收到一个数据包就确认,而是收到一批同时确认
  • 确认号:下一个期望收到的字节

TCP拥塞窗口:控制发送方向网络中的发送速率

  • 发送窗口 = min(接收窗口, 拥塞窗口)
  • ssthresh:网络拥堵时变为cwnd的一半
  • 慢开始:逐步增大cwnd数量,指数倍增大
  • 加法增大:cwnd>ssthresh后,每次+1
  • 快恢复:出现拥塞后cwnd的值不从1开始,而是直接从ssthresh开始加法增大
  • 在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

在这里插入图片描述

TCP 如何保证可靠性

  1. 三次握手建立连接
  2. 校验和
  3. 序列号和ACK机制
  4. 超时重传和快重传

三次握手

三次握手

为什么两次不行?

  • 确认通信双方都有接受数据和发送数据的能力
  • 为了防止已失效的连接请求报文段突然又传送到了服务端,因而产脏连接

四次挥手

在这里插入图片描述

TIME_WAIT状态

收到被动关闭一方的FIN报文后,主动关闭方需要等待2MSL(报文最大生存时间)才关闭,防止主动关闭方发送的ACK报文丢失,超时后被动关闭方重新发送FIN报文

影响

在socket的TIME_WAIT状态结束之前,该socket所占用的本地端口号将一直无法释放

包失序和包重复问题

包失序

包失序主要是由于IP层的网络拥堵或者选择了不同的传输链路

  • 反向链路(ACK传递):可能会连续发送多个相同的ACK,触发快重传

包重复

连续发送三个ACK,可能引发快重传,在ACK中添加重复的报文信息解决

计算机网络协议

DNS:域名解析协议

ICMP:ICMP协议的核心作用就是对上层协议报告数据包传递时的差错

ARP:IP地址转换为MAC地址

FTP:文件传输协议

HTTPS

  • 默认端口号:443

对称加密

  • 顾名思义就是加密和解密都是使用同一个密钥
  • 传递密钥的过程中如果被截获,则会产生安全问题

非对称加密

加密和解密需要使用两个不同的密钥,使用公钥加密只有使用私钥才能解开

HTTPS传输数据的流程

解析文章
在这里插入图片描述

TCP的粘包和拆包

TCP时面向流的,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

为什么会产生粘包和拆包呢?

  • 要发送的数据小于TCP发送缓冲区的大小,TCP将多次写入缓冲区的数据一次发送出去,将会发生粘包;
  • 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包;
  • 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生拆包;
  • 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。

解决方案

  • 发送端将每个数据包封装为固定长度
  • 在数据尾部增加特殊字符进行分割

常见问题

打开一个网页,整个过程

  1. DNS解析
  2. 建立TCP连接
  3. 发送HTTP请求
  4. 服务器处理HTTP请求
  5. 返回HTTP响应
  6. 浏览器渲染

GET和POST

GETPOST
幂等非幂等
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值