计算机网络汇总

计算机网络体系结构

主要讲解TCP/IP体系结构:

TCP

Transmission Control Protocol,即 传输控制协议

1.属于 传输层通信协议

2.基于TCP的应用层协议有HTTPSMTPFTPTelnetPOP3

特点

建立连接过程(三次握手)

报文格式

首部前20个字符固定、后面有4n个字节是根据需而增加的选项

故 TCP首部最小长度 = 20字节

为什么要三次握手

三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手:Client 什么都不能确认;Server 确认了对方发送正常

第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常Server 确认了:自己接收正常,对方发送正常

第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送接收正常

所以三次握手就能确认双发收发功能都正常,缺一不可。

SYN:同步序列编号(Synchronize Sequence Numbers)。是TCP/IP建立连接时使用的握手信号。

为什么要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了。

传了 SYN,为啥还要传 ACK

双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。

ACK(Acknowledgement) 确认字符 ,在数据通信传输中,接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。

SYN(synchronous建立联机)

ACK(acknowledgement 确认)

PSH(push传送) FIN(finish结束)

RST(reset重置)

URG(urgent紧急)

Sequence number(顺序号码)

Acknowledge number(确认号码)

SYN表示建立连接,FIN表示关闭连接,ACK表示响应,PSH表示有 DATA数据传输,RST表示连接重置。

释放连接过程

为什么要四次挥手

举个例子:A 和 B 打电话,通话即将结束后:

1.A 说“我没啥要说的了”,

2.B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,

3.于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,

4.A 回答“知道了”,这样通话才算结束。

因为是“全双工”,所以需要俩边都断开了连接

为什么需要等待 2MSL

MSL(Maximum Segement Lifetime)

因为如果不等待的话,如果服务端还有很多数据包要给客户端发,且此时客户端端口被新应用占据,那么就会接收到无用的数据包,造成数据包混乱,所以说最保险的方法就是等服务器发来的数据包都死翘翘了再启动新应用。

  • 1个 MSL 保证四次挥手中主动关闭方最后的 ACK 报文能最终到达对端
  • 1个 MSL 保证对端没有收到 ACK 那么进行重传的 FIN 报文能够到达

UDP

User Datagram Protocol,即 用户数据报协议

属于 传输层通信协议

基于UDP的应用层协议有 TFTPSNMPDNS

特点

报文段格式

HTTP

  • HTTP协议 属于 应用层

特点

工作方式

  • HTTP协议采用 请求 / 响应 的工作方式
  • 具体工作流程如下:

HTTP报文详解

请求报文

报文结构

请求行
  • 结构
    请求行的组成 = 请求方法 + 请求路径 + 协议版本

注:空格不能省

此处特意说明GET、PSOT方法的区别:

请求头

采用”header(字段名):value(值)“的方式

1. 请求和响应报文的通用Header

常见请求Header

请求体
  • 作用:存放 需发送给服务器的数据信息

  • 使用方式:共3种

总结

响应报文

报文结构

状态行
  • 组成
    状态行有协议版本、状态码 &状态信息组成

其中,空格不能省

具体介绍

响应头

类似

响应体

类似

HTTP 与HTTPS的区别

HTTP1.0 与 HTTP1.1的区别

主要区别主要体现在:

  1. 缓存处理

    在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,

    HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

  2. 带宽优化及网络连接的使用

    HTTP1.0中,存在一些浪费带宽的现象,

    例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,

    HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

  3. 错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,

    如409(Conflict)表示请求的资源与资源的当前状态发生冲突;

    410(Gone)表示服务器上的某个资源被永久性的删除。

  4. Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。

    但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。

    HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。

  5. 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,

    在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,

    在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP 2 改进

改进性能:

  • 头部压缩
  • 多路信道复用
  • Server Push

HTTP长连接

Connection: keep-alive

Socket

  • 即套接字,是应用层 与 TCP/IP 协议族通信的中间软件抽象层,表现为一个封装了 TCP / IP协议族 的编程接口(API)

  1. Socket不是一种协议,而是一个编程调用接口(API),属于传输层(主要解决数据如何在网络中传输)

  2. 对用户来说,只需调用Socket去组织数据,以符合指定的协议,即可通信

  • 成对出现,一对套接字:
Socket ={(IP地址1:PORT端口号),(IP地址2:PORT端口号)}
  • 一个 Socket 实例 唯一代表一个主机上的一个应用程序的通信链路

在浏览器中输入url地址 ->> 显示主页的过程

其他知识

IP地址(IPv4地址)

  • 定义 连接在Internet中的每一台主机(或 路由器)的全球唯一的标识符
  • 组成 IP地址 = 32位 = 网络号 + 主机号;即IP地址::={<网络号>,<主机号>}

其中:

  1. 网络号:标志主机(或路由器)所连接到的网络。一个网络号在整个因特网范围内必须是唯一的。
  2. 主机号:标志该主机(或路由器)。一个主机号在它面前的网络号所指明的网络范围必须是唯一的。

不同类型的IP地址,其主机号 & 网络号所占字节数不同;故:一个IP地址在整个网络范围内是唯一的

  • 分类 传统的IP地址是分类的地址,分为A,B,C,D,E五类

区别在于网络号 & 主机号占的字节数不同

  • 特别注意:在各类IP地址中,有一些IP地址用于特殊用途,不能用于做主机IP地址

ICMP协议

  • 定义 Internet Control Message Protocol,即 网际控制报文协议
  1. 属于IP层协议
  2. 注:ICMP报文不是高层协议,而是作为IP层数据报的数据,加上数据报首部,组成IP数据报发出去
  • 作用 更有效地转发IP数据包 & 提高交付成功的机会

同时允许主机 / 路由器报告差错 & 异常情况

  • 分类 ICMP差错报告报文 & ICMP询问报文

  • 主要应用 PING(分组网间探测)、Traceroute(跟踪1个分组从源点到终点的路径,

    原理 = 从源主机向目的主机发送一连串的IP数据报)

下面,将主要介绍Ping的过程

Ping的过程

  • 定义 Packet InterNet Groper,即 分组网间探测

ICMP报文的一个重要应用:使用了IPCM回送请求 & 回送回答报文

路由器与交换机的区别

cookie,session,token

Cookie

cookie 是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器。

由于cookie是存在客户端上的,所以浏览器加入了一些限制确保cookie不会被恶意使用,同时不会占据太多磁盘空间,所以每个域的cookie数量是有限的。

Session

session 从字面上讲,就是会话。

这个就类似于你和一个人交谈,你怎么知道当前和你交谈的是张三而不是李四呢?对方肯定有某种特征(长相等)表明他就是张三。

session 也是类似的道理,服务器要知道当前发请求给自己的是谁。

为了做这种区分,服务器就要给每个客户端分配不同的“身份标识”,然后客户端每次向服务器发请求的时候,都带上这个“身份标识”,服务器就知道这个请求来自于谁了。

至于客户端怎么保存这个“身份标识”,可以有很多种方式,对于浏览器客户端,大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上,用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全。

可是session有一个缺陷:如果web服务器做了负载均衡,那么下一个操作请求到了另一台服务器的时候session会丢失。

Token

在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中,tokens 是多用户下处理认证的最佳方式。

以下几点特性会让你在程序中使用基于Token的身份验证

  1. 无状态、可扩展
  2. 支持移动设备
  3. 跨程序调用
  4. 安全

那些使用基于Token的身份验证的大佬们

大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

基于服务器验证方式暴露的一些问题

  1. Seesion:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。
  2. 可扩展性:在服务端的内存中使用Seesion存储登录信息,伴随而来的是可扩展性问题。
  3. CORS(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源,就可以会出现禁止请求的情况。
  4. CSRF(跨站请求伪造):用户在访问银行网站时,他们很容易受到跨站请求伪造的攻击,并且能够被利用其访问其他的网站。

基于Token的验证原理

NoSession意味着你的程序可以根据需要去增减机器,而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

  1. 用户通过用户名和密码发送请求。
  2. 程序验证。
  3. 程序返回一个签名的token 给客户端。
  4. 客户端储存token,并且每次用于每次发送请求。
  5. 服务端验证token并返回数据。

Tokens的优势

无状态、可扩展

基于这种无状态和不存储Session信息,负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中,则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时,可能会造成一些拥堵。

安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。

即使在客户端使用cookie存储token,cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中,让我们少了对session操作。

token是有时效的,一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效,token有撤回的操作,通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

可扩展性

Tokens能够创建与其它程序共享权限的程序。例如,能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时,我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时,可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据,我们可以通过建立自己的API,得出特殊权限的tokens。

无差错传输

下面,将详细讲解TCP协议的无差错传输

滑动窗口协议

对于发送端:

1.每收到一个确认帧,发送窗口就向前滑动一个帧的距离

2.当发送窗口内无可发送的帧时(即窗口内的帧全部是已发送但未收到确认的帧),发送方就会停止发送,直到收到接收方发送的确认帧使窗口移动,窗口内有可以发送的帧,之后才开始继续发送。

对于接收端:

1.当收到数据帧后,将窗口向前移动一个位置,并发回确认帧,若收到的数据帧落在接收窗口之外,则一律丢弃。

自动重传请求协议ARQ(针对 出错重传)

类型1:停等式ARQ(Stop-and-Wait)

  • 原理:(单帧滑动窗口)停止 - 等待协议 + 超时重传

即 :发送窗口大小=1、接收窗口大小=1

  • 停止 - 等待协议的协议原理如下:
  1. 发送方每发送一帧,要等到接收方的应答信号后才能发送下一帧
  2. 接收方每接收一帧,都要反馈一个应答信号,表示可接下一帧
  3. 若接收方不反馈应答信号,则发送方必须一直等待

类型2:后退N帧协议

也称:连续ARQ协议

  • 原理
    多帧滑动窗口 + 累计确认 + 后退N帧 + 超时重传

即 :发送窗口大小>1、接收窗口大小=1

  • 具体描述
    a. 发送方:采用多帧滑动窗口的原理,可连续发送多个数据帧 而不需等待对方确认
    b. 接收方:采用 累计确认 & 后退N帧的原理,只允许按顺序接收帧。具体原理如下:

本示例 = 源站 向 目的站 发送数据帧。具体示例如下:

类型3:选择重传ARQ(Selective Repeat)

  • 原理
    多帧滑动窗口 + 累计确认 + 后退N帧 + 超时重传

即 :发送窗口大小>1、接收窗口大小>1

类似于类型2(后退N帧协议),此处仅仅是接收窗口大小的区别,故此处不作过多描述

  • 特点
    a. 优:因连续发送数据帧而提高了信道的利用率
    b. 缺:重传时又必须把原来已经传送正确的数据帧进行重传(仅因为这些数据帧前面有一个数据帧出了错),将导致传送效率降低

由此可见,若信道传输质量很差,导致误码率较大时,后退N帧协议不一定优于停止-等待协议

流量控制 & 拥塞控制(针对 速度匹配)

流量控制

  • 特别注意:死锁问题

拥塞控制

拥塞:对网络中的资源需求 > 该资源所能提供的部分

与 “流量控制”的区别

  • 共分为2个解决方案:慢开始 & 拥塞避免、快重传 & 快恢复

其中,涉及4种算法,即 慢开始 & 拥塞避免、快重传 & 快恢复

慢开始 & 拥塞避免

预备知识:

拥塞窗口

慢开始算法

  • 原理
    当主机开始发送数据时,由小到大逐渐增大 拥塞窗口数值(即 发送窗口数值),从而 由小到大逐渐增大发送报文段
  • 目的
    开始传输时,试探网络的拥塞情况
  • 具体措施

拥塞避免

慢开始 & 拥塞避免

  • 原理
    使得拥塞窗口(cwnd)按线性规律 缓慢增长:每经过一个往返时间RTT,发送方的拥塞窗口(cwnd)加1
  1. 拥塞避免 并不可避免拥塞,只是将拥塞窗口按现行规律缓慢增长,使得网络比较不容易出现拥塞
  2. 相比慢开始算法的加倍,拥塞窗口增长速率缓慢得多
  • 示意图

  • 为了防止拥塞窗口(cwnd)增长过大而引起网络拥塞,采用慢开始 & 拥塞避免 2种算法,具体规则如下

快重传 & 快恢复

预备知识:

快重传算法

原理

  1. 接收方 每收到一个失序的报文段后 就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方),而不要等到自己发送数据时才进行捎带确认
  2. 发送方只要一连收到3个重复确认就立即重传对方尚未收到的报文段,而不必 继续等待设置的重传计时器到期

作用
由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%

示意图

快恢复

当发送方连续收到3个重复确认后,就:

  1. 执行 乘法减小 算法:把 慢开始门限(ssthresh)设置为 出现拥塞时发送方窗口值的一半 = 拥塞窗口的1半
  2. 将拥塞窗口(cwnd)值设置为 慢开始门限ssthresh减半后的数值 = 拥塞窗口的1半
  3. 执行 加法增大 算法:执行拥塞避免算法,使拥塞窗口缓慢地线性增大。

注:

  1. 由于跳过了拥塞窗口(cwnd)从1起始的慢开始过程,所以称为:快恢复
  2. 此处网络不会发生网络拥塞,因若拥塞,则不会收到多个重复确认报文

快重传 & 快恢复

  • 示意图

参考链接

图片来源:《图解HTTP》

https://juejin.cn/post/6844903592965439501

https://juejin.cn/post/6844903662838349838#heading-14

https://zhuanlan.zhihu.com/p/63061864

https://juejin.cn/post/6844903951335178248#heading-41

posted @ 2021-08-09 21:24  ML李嘉图  阅读(108)  评论(2编辑  收藏  举报