计算机网络总结笔记

计算机网络

OSI 七层模型, TCP/IP 四层模型

image-20210326085838754

应用层:为特定应用程序提供数据传输服务。( TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet)

表示层:对上层信息进行变换,保证一个主机应用层信息被另一个主机的应用程序理解,表示层的数据转换包括数据的加密、压缩、格式转换

会话层:管理主机之间的会话进程,即负责建立、管理、终止。

传输层:提供端对端的接口。( TCP,UDP)

网络层:为***数据包***选择路由。(IP,ICMP,ARP,RARP)

数据链路层:传输有地址的,错误检测功能( SLIP,CSLIP,PPP,ARP,RARP,MTU)

物理层:以二进制数据形式在物理媒体上传输数据。 ISO2110,IEEE802,IEEE802.2

image-20210326090217680

**SMTP(邮件发送和中转):*全称是“Simple Mail Transfer Protocol”,即简单邮件传输协议。它是一组用于从源地址到目的地址传输邮件的规范,通过它来控制邮件的中转方式。SMTP 协议属于 TCP/IP 协议簇,它帮助每台计算机在发送或中转信件时找到下一个目的地。SMTP 服务器就是遵循 SMTP 协议的发送邮件服务器。

SMTP 认证,简单地说就是要求必须在提供了账户名和密码之后才可以登录 SMTP 服务器,这就使得那些垃圾邮件的散播者无可乘之机。   增加 SMTP 认证的目的是为了使用户避免受到垃圾邮件的侵扰。

**POP3(邮件接收):****是Post Office Protocol 3的简称,即邮局协议的第3个版本,它规定怎样将个人计算机连接到Internet的邮件服务器和下载电子邮件的电子协议。

**IMAP(邮件接收):****全称是Internet Mail Access Protocol,即交互式邮件存取协议,它是跟POP3类似邮件访问标准协议之一。不同的是,开启了IMAP后,您在电子邮件客户端收取的邮件仍然保留在服务器上,同时在客户端上的操作都会反馈到服务器上。

IP地址的分类

image-20210326090554166

在IP地址3种主要类型里,各保留了3个区域作为私有地址,其地址范围如下: A类地址:10.0.0.0~10.255.255.255 B类地址:172.16.0.0~172.31.255.255 C类地址:192.168.0.0~192.168.255.255

TCP 与UDP

Tcp是一种面向连接的,可靠的、基于字节流的、点对点的传输层通信协议

UDP是一种面向无连接的、不可靠的、面向****报文****的,有单播多播和广播功能的传输层协议。

TCP报文格式

image-20210326090910116

较重要的字段:

(1)序号:Seq,占32位,数据发送方发送TCP报文时对数据进行编号;

(2)确认号:ack,占32位,只有当ACK为1时,确认序号段才有效,ack=Seq+1;

(3)标志位(Flags)

​ URG:紧急指针有效;

​ ACK:ack字段有效;

​ PSH:将报文尽快交给应用层;

​ RST:重置连接;

​ SYN:发起请求;

​ FIN:释放连接。

(4)检验和:奇偶校验,此校验和是针对整个TCP报文段的,包括TCP报头和TCP报文数据段,以2个字节进行计算所得。由发送端计算和存储,并由接收端进行验证。

(5)窗口:滑动窗口大小,用来告知****发送端**收端的缓存大小****,以此控制发送端发送数据的速率,从而达到流量控制。窗口大小是2个字节,因而窗口大小最大为65536。

需要注意的是:

不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1,两端配对。

TCP的三次握手和四次挥手

三次握手

image-20210326091311949

建立连接前server端需要监听端口,所以初始状态是LISTEN。

1、client端建立连接,发送一个SYN同步包,发送之后状态变成SYN_SENT

2、 server端收到SYN之后,同意建立连接,返回一个ACK响应,同时也会给client发送一个SYN包,发送完成之后状态变为SYN_RCVD

3、 client端收到server的ACK之后,状态变为ESTABLISHED,返回ACK给server端。server收到之后状态也变为ESTABLISHED,连接建立完成。

在客户端与服务器端传输的TCP报文中,双方的确认号ack和序号Seq的值,都是在彼此ack和Seq值的基础上进行计算的,这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失,便无法继续"握手",以此确保了"三次握手"的顺利完成。

为什么是三次握手而不是两次?

为了防止连接释放后服务端收到客户端过时失效的请求,造成错误。在连接释放后,之前客户端发送的某个请求可能由于网络原因姗姗来迟,如果采用两次握手,服务端会在收到这个过时请求后建立连接并向客户端发起连接确认,客户端由于之前并没有向服务端发送过请求不会理会这个请求,但此时服务端会保持此链接等待回应。当这种无效过时的请求到达一定数量时会浪费服务器的大量资源。而三次握手就能够解决这一问题。

四次挥手

image-20210326091621496

1、 client端向server发送FIN包,进入FIN_WAIT_1状态,这代表client端已经没有数据要发送了

2、 server端收到之后,返回一个ACK,进入CLOSE_WAIT等待关闭的状态,因为server端可能还有没有发送完成的数据

3、 等到server端数据都发送完毕之后,server端就向client发送FIN,进入LAST_ACK状态

4、 client收到ACK之后,进入TIME_WAIT的状态,同时回复ACK,server收到之后直接进入CLOSED状态,连接关闭。但是client要等待2MSL(报文最大生存时间)的时间,才会进入CLOSED状态。

为什么要等待2MSL才关闭连接

1、为了保证连接的可靠关闭。如果server没有收到最后一个ACK,那么就会重发FIN。

2、为了避免端口重用带来的数据混淆。如果client直接进入CLOSED状态,又用相同端口号向server建立一个连接,上一次连接的部分数据在网络中延迟到达server,数据就可能发生混淆了。

TCP如何让保证可靠传输

(1)数据包校验:目的是检测数据包在传输过程中有无发生变化,如果有则将其丢弃,等待发送端超时重传。

(2)数据包排序:TCP在发送数据时会将数据包拆分成许多小的数据包并进行编号,当数据包发送到接收端时可能是无序的,需要接收端对数据包进行重新排序后再发给应用层。

(3)确认机制:接收端收到一个数据包后,会给发送端发送一个确认。

(4)超时重传:发送端在发送一个数据包后会启动一个定时器,如果超过指定时间都没有收到接收端发送的确认,会重新发送这个数据包。

(5)丢弃重复数据包:接收端收重复的数据包后会将其丢弃。

(6)流量控制:TCP的接收端和发送端都有一个固定的缓冲区,且不允许发送端发送大于接收端缓冲区的数据,这能防止较快主机使较慢主机发生缓冲溢出。TCP使用的流量控制协议是窗口大小可变的窗口协议。

(7)拥塞控制

特点:慢启动、快增长

image-20210326091955967

快速重传

超时重新发送的机制:发送方送出一个TCP片段,然后开始等待并计时,如果RTO时间之后还没有收到ACK回复,发送方则重新发送。TCP协议有可能在计时完成之前启动重新发送,也就是利用快速重新发送(fast-retransmission)。快速发送机制如果被启动,将打断计时器的等待,直接重新发送TCP片段。

由于IP包的传输是无序的,所以接收方有可能先收到后发出的片段,也就是乱序(out-of-order)片段。乱序片段的序号并不等于最近发出的ACK回复号。已接收的文本流和乱序片段之间将出现空洞(hole),也就是等待接收的空位。比如已经接收了正常片段5,6,7,此时又接收乱序片段9。这时片段8依然空缺,片段8的位置就是一个空洞。

补上空洞

TCP协议规定,当接收方收到乱序片段的时候,需要重复发送ACK。比如接收到乱序片段9的时候,接收方需要回复ACK。回复号为8 (7+1)。此后接收方如果继续收到乱序片段(序号不是8的片段),将再次重复发送ACK=8。当发送方收到3个ACK=8的回复时,发送方推断片段8丢失。即使此时片段8的计时器还没有超时,发送方会打断计时,直接重新发送片段8,这就是快速重新发送机制

为什么是三个重复ACK才快重传?

两次duplicated ACK肯定是乱序造成的!

丢包肯定会造成三次duplicated ACK!

参考:https://www.zhihu.com/question/21789252

TCP拆包和粘包

image-20210326093132918

TCP粘包出现原因

简单得说,在流传输中出现,UDP不会出现粘包,因为它有消息边界(参考Windows网络编程)

1发送端需要等缓冲区满才发送出去,造成粘包

2接收方不及时接收缓冲区的包,造成多个包接收

无论拆包还是粘包本质问题都是无法区分包界限

针对这个问题,一般有3种解决方案:

(1)发送固定长度的消息

(2)把消息的长度与消息一块发送

(3)使用特殊标记来区分消息间隔(比如netty中LineBasedFrameDecoder解析器就是利用换号符号做分割。)

UDP报文格式

UDP请求头

image-20210326092754095

  • 源端口(Source port)
  • 目的端口(Destination port)
  • 报文长度(Length)

16 bits,指示UDP报文(首部和数据)的总长度。最小8 bytes,只有首部,没有数据。最大值为65535 bytes。实际上,由于IPv4分组的最大数据长度为(65535 - 20 = 65515) bytes,UDP的报文长度不超过65515 bytes。IPv6允许UDP的长度超过65535,此时length字段设为0。

  • 校验和(Checksum)

UDP报文结构相较于TCP简单很多,且面向无连接的,因此速度远快于Tcp

UDP应用场景:

直播、实时游戏、IOT物联网

HTTP和HTTPS

Http基于tcp协议传输,明文传输,无状态,客户端和服务器都不能验证对方的身份;

Https基于SSL(Secure Socket layer),SSL基于TCP,Https是身披一层ssl外衣的HTTP,是添加了加密和验证的HTTP。

  • 端口:http使用的是80端口,https使用的是443端口

  • 资源消耗:http消耗的资源更少,而https由于需要加密解密以及安全证书验证,会占用更多的cpu和内存资源。

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段。

HTTP请求头结构

image-20210326093608071

HTTP不同版本的区别

HTTP/0.9

  • 只接受GET一种请求方式,并且不支持请求头;

  • 只支持纯文本一种内容;

  • 无状态性,每个事务独立进行处理,事务结束时就释放这一个连接。

HTTP/1.0

  • 仅支持GET,POST和HEAD等请求方法,支持信息头(HTTP header);
  • 除文本外,还支持图像,音频,视频等二进制文件;
  • 支持Cache,新增了状态码(status code),权限authorization),内容编码(content encoding)和缓存等;

但是1.0版本的工作方式是每次TCP连接只能发送一个请求,当服务器响应后就会关闭这次连接,下一个请求需要再次建立TCP连接,就是不支持 keep-alive。 TCP连接的建立成本很高,因为需要客户端和服务器三次握手,并且开始时发送速率较慢(slow start)。所以,HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多,这个问题就愈发突出了。为了解决这个问题,有些浏览器在请求时,用了一个非标准的Connection字段。

HTTP/1.1

  • 加入了持久连接(persistent connection),即TCP连接默认不关闭,可以被多个请求复用;
  • 加入管道机制,在同一个TCP连接里,允许多个请求同时发送,增加了并发性,进一步改善HTTP协议的效率;
  • 新增了PUT,PATCH,DELETE等请求方式
  • 新增了HOST字段,用来指定服务器的域名;
  • 支持文件断点续传。

HTTP/2.0

  • 二进制协议:Http/1.1版的数据体可以是文本的,也可以是二进制的。但HTTP/2.0所有的信息和数据都是二进制,并统称为“帧”(frame):头信息帧和数据帧。
  • 多路复用:HTTP/2.0复用TCP连接,在一个连接里。客户端和浏览器都可以同时发送多个请求或回应。(多路复用!!)
  • 头部信息压缩:
  • 服务器推送:HTTP/2.0允许服务器未经请求就可以主动向客户端发送资源。

HTTP请求方式

image-20210326094044965

DNS请求过程

image-20210326094247645

  1. 浏览器首先会查询自身的缓存中是否解析过这个域名,如果有,解析结束。
  2. 如果没有,浏览器会检查操作系统缓存中有没有对应的已解析结果。(在windows中可通过c盘里一个叫hosts的文件来设置,如果你在这里指定了一个域名对应的ip地址,那浏览器会首先使用这个ip地址。但是这种操作系统级别的域名解析规程也被很多黑客利用,通过修改你的hosts文件里的内容把特定的域名解析到他指定的ip地址上,造成所谓的****域名劫持****。所以在windows7中将hosts文件设置成了readonly,防止被恶意篡改。)
  3. 如果还是没有命中域名,才会向本地DNS服务器发起域名解析请求(这台服务器一般在你的城市的某个角落,距离你不会很远,并且这台服务器的性能都很好,一般都会缓存域名解析结果,大约80%的域名解析到这里就完成了。)
  4. 如果Local DNS server还是没有命中,直接跳到Root Server 域名服务器请求解析;
  5. Root Server 给Local DNS Server 一个查询域名的主域名服务器(gTLD Server,国际顶尖域名服务器,如.com .cn .org等)地址
  6. 此时LDNS再发送请求给上一步返回的gTLD
  7. 接受请求的gTLD查找并返回这个域名对应的Name Server的地址,这个Name Server就是网站注册的域名服务器
  8. Name Server根据映射关系表找到目标ip,返回给LDNS
  9. LDNS缓存这个域名和对应的ip
  10. LDNS把解析的结果返回给用户,用户根据TTL值缓存到本地系统缓存中,域名解析过程至此结束

HTTP请求过程

  1. 对www.baidu.com这个网址进行DNS域名解析,得到对应的IP地址

  2. 根据这个IP,找到对应的服务器,发起TCP的三次握手

  3. 建立TCP连接后发起HTTP请求

  4. 服务器响应HTTP请求,浏览器得到html代码

  5. 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等)(先得到html代码,才能去找这些资源)

  6. 浏览器对页面进行渲染呈现给用户

  7. 服务器关闭关闭TCP连接

HTTPS原理及流程

HTTPS的整体过程分为证书验证数据传输阶段,具体的交互过程如下:

image-20210326094710793

证书验证阶段:

① 浏览器发起 HTTPS 请求

② 服务端返回 HTTPS 证书

③ 客户端验证证书是否合法,如果不合法则提示告警

数据传输阶段:

④ 当证书验证合法后,在本地生成随机数

⑤ 通过公钥加密随机数,并把加密后的随机数传输到服务端

⑥ 服务端通过私钥对随机数进行解密

⑦ 服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输

end

评论