计算机网络知识点

网络模型

  • 物理层:物理层处于OSI参考模型的最低层。物理层的主要功能是利用物理传输介质为数据链路层提供物理连接,以透明地传送比特流。
  • 数据链路层:数据链路层在物理层提供比特流传输服务的基础上,在通信实体之间建立数据链路连接,传送以帧为单位的数据,通过差错控制、流量控制方法,变有差错的物理线路为无差错的数据链路。
  • 网络层:网络层主要任务是通过执行路由选择算法,为报文分组通过通信子网选择最适当的路径。它是OSI参考模型七层中最复杂的一层。
  • 传输层:传输层是向用户提供可靠的端到端服务,透明地传送报文。
  • 会话层:会话层的主要目的是组织同步的两个会话用户之间的对话,并管理数据的交换。
  • 表示层:表示层主要用于处理两个通信系统间信息交换的表示方式,它包括数据格式变换、数据加密与解密、数据压缩与恢复等功能。
  • 应用层:应用层是OSI参考模型的最高层。应用层不仅要提供应用进程所需要信息交换和远程操作,而且还要作为应用进程的用户代理,完成一些为进行语义上有意义的信息交换所必须的功能。

TCP首部

  • 源端口和目的端口,各2字节
  • 序号,4字节,面向字节流传输,标识当前报文段发送数据的起始编号,接受方根据起始编号和数据大小,就可以推算出下一个应该接受报文的起始编号
  • 确认号,4字节,下一个希望收到报文的起始编号,即表示:N之前编号的数据已经成功收到
  • 数据偏移,4字节,数据部分离报文段起始位置有多远
  • 保留位,6字节,暂时没用,留着以后使用
  • URG:说明有紧急数据,应尽快发送
  • ACK:建立连接后所有ACK报文必须置为1
  • PSH:。。。
  • RST:出现了严重错误,必须重新建立连接
  • SYN:请求连接
  • FIN:释放连接
  • 窗口:发送本报文段的一方的接受窗口
  • 检验和:检验报文的首部和数据是否发送改变
  • MSS:规定的最大报文长度

三次握手与四次挥手

  • 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。
  • 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s)。 同时会把客户端的 ISN + 1 作为 ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_REVD 的状态。
  • 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 establised 状态。
  • 服务器收到 ACK 报文之后,也处于 establised 状态,此时,双方已建立起了链接。

  • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
  • 第二次握手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。
  • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
  • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。 需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
  • 服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。

第2次握手传回了ACK,为什么还要传回SYN?
答:接收端传回发送端所发送的ACK是为了告诉客户端,我接收到的信息确实就是你所发送的信号了,这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。

为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:连接时,当服务端收到客户端的 SYN 连接请求报文后,可以直接发送 SYN+ACK 报文,其中 ACK 报文是用来应答的,SYN 是用来同步的。但关闭连接时,服务端收到 FIN 报文后,可能不会立即发送 FIN 报文,因为服务端可能该发送的报文还没有发完,因此只能先回复一个 ACK 报文表示确认收到了。等服务端所有报文都发送完了,才回复 FIN 信号关闭连接。故需要四次握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:一个是当服务端没有收到ACK时,有时间重发ACK;二是经过2MSL就可以使本次连接所产生的所有报文都从网络中消失,下次连接就不会出现旧的连接请求报文。

MSL是最大报文生存时间,2MSL就是发送+回复的最大时间。如果ACK丢包了,那么一定会在2MSL之内收到服务端重发的FIN包。

为什么不能用两次握手进行连接?
答:客户端发出连接请求,未收到确认,于是重发,接收到确认,建立连接。但之前的连接请求却又到了服务端,服务端发送确认报文段,又建立了一次连接。

如果已经建立了连接,但是客户端突然出现故障了怎么办?
答:TCP还设有一个保活计时器,服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

校验和

将数据段都当做16位整数,将这些加起来,最后取反,得到校验和。

发送方发送之前计算校验和并填充,接收方以同样的方式计算,进行比对。

确认应答与序列号

TCP对每个字节的数据都进行编号,就是序列号。接收方每次收到数据后,都会发送ACK报文以确认,报文中有相应的确认序列号,告诉发送方,下一次的数据应该从哪里开始发。

另一个作用是排序,因为数据包不一定是按序到达的,因此可以按序列号对数据包排序。

TCP超时重传

超时重传指的是发送数据包到接收确认包之间的时间,如果超过了这个时间就会被认为丢包。(可能是数据丢包,也可能是确认报文丢包)

TCP每发送一个报文段,就会设置一次计时器。计时器设置的重传时间到了,还没有收到确认,就要重传这一报文段。

RTO:重传超时时间,发送端发送数据到重传数据的这一段等待时间
RTT:连接往返时间,发送端从发送TCP包接受到对应的立即响应所耗费的时间

RTO 和 RTT 比较示意图

ARQ协议

停止等待ARQ:发完一个分组就停止,等待确认,超时就重发,确认收到再发送下一个分组。缺点是信道利用率低。

连续ARQ:维护一个发送窗口,分组内可用连续发送出去,接受方采用累计确认,对按序到达的最后一个发组发送确认,表明之前的已经全部收到了。
缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。

TCP流量控制

接受端缓冲区大小有限,发送的太快太多接受端来不及处理。

如果一个一个发数据段,等确认了再发下一个,效率就比较低。

滑动窗口是流量控制和核心,存在与TCP首部,TCP首部有个window字段,用于接受端告诉发送端自己还有多少缓冲区可以接收数据。

当window字段为0,就会停止发送数据。那什么时候可以继续发送数据?

一种可能是接收方去发一个报文去通知发送端可以继续发,但要是这个报文丢了,就会再次陷入僵局。

因此采取的策略当收到win=0的报文后,就开启一个计时器,每隔一段时间就发个测试报文测试一下,打听一下是否可以发数据了。

TCP拥塞控制

防止发送方发的太快,使得网络来不及处理,从而导致网络拥塞。

  1. 慢开始:设置拥塞窗口cwnd为1,然后以指数增长(乘2),逐步发送数据。
  2. 拥塞避免:为了防止cwnd增加过快而导致网络拥塞,所以需要设置一个慢开始门限ssthresh状态变量,窗口大小增长到门限值,就改为执行拥塞避免算法,每经历过一次往返时间就使cwnd增加1。
  3. 快速重传:累计收到三个同样的确认报文,说明下一个报文还没有到达,认为拥塞发生了,立即重传该报文。
  4. 快速恢复:将当前窗口大小和门限值调整为当前窗口的一半,开始执行拥塞避免算法。

流量控制和拥塞控制的区别:

  • 一个是丢包在接受端上,一个是丢包在路由器上。
  • 一个是怕接受端来不及处理,一个怕网络拥塞,网络来不及处理

TCP和UDP区别

用户数据报协议 UDP(User Datagram Protocol)
传输控制协议 TCP(Transmission Control Protocol)

  • TCP面向连接,UDP不需要建立连接,随时想发就发,也不会对数据报进行任何拆分,也就说明UDP是不可靠传输
  • UDP并不只是一对一的,有单播,多播,广播的功能
  • UDP面向报文,TCP面向字节流
  • UDP头部更小(源端口,目的端口,数据长度,校验和),只有8个字节,传输效率更高
  • TCP有流量控制,拥塞控制来保证安全性,UDP没有
  • UDP适用于事实通信(电话,直播),TCP适用于可靠传输(文件传输)

UDP如何实现可靠传输

感觉这个题就是个坑,毕竟UDP存在的意义就是无连接的,只管无脑发送,不管反馈。想靠谱就用TCP呗,多好用的东西。

不过真的想要实现的话,首先想想TCP实现可靠传输的办法。传输层是没有办法保证的,因此只能通过UDP来实现了。实现一些确认机制,重传机制,窗口确认机制。

HTTP协议

HTTP(超文本传输协议),基于TCP/IP通信协议来传递数据,属于应用层的面向对象的协议。
特点:

  • 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。
  • 灵活:HTTP允许传输任意类型的数据对象。
  • 无连接:无连接的含义是限制每次连接只处理一个请求。
  • 无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传。
  • 支持B/S及C/S模式。

从输入URL到页面加载发生了什么?

  1. DNS 域名解析
    当你输入了 www.google.com 并按下回车后,浏览器检查输入框,发现不是 ip 地址,于是去 浏览器缓存 里面找有没有相关记录,发现没有,那就继续去 系统缓存 找,也就是系统中的 hosts 文件,还是没有,又继续去 路由器缓存 里面找,查看的是路由器映射表。接着,计算机将域名发送给 本地DNS服务器,也就是 提供本地连接的服务商,本地DNS服务器找不到的话,会将域名发送到 根域名服务器,也就是 ‘.’,找不到就返回 顶级域名服务器 —— .com 的IP地址,再请求 顶级域名服务器IP 返回 二级域名服务器 —— google.com 的IP地址…直到找到对应的IP地址,然后返回给浏览器。
  2. 发起 TCP 连接(三次握手)
    知道IP地址后,传输层的TCP协议就可以向远端服务器发起连接请求了。
  3. 发送 HTTP 请求,接受 HTTP 响应
    连接上了,可以传输了。计算机需要将用户输入的地址封装成 HTTP Request 请求报文,发送到服务器,服务器收到请求后会发出应答,即响应数据。
    HTTP请求报文格式:请求行+请求头+空行+消息体,请求行包括请求方式(GET/POST/DELETE/PUT)、请求资源路径(URL)、HTTP版本号。
    HTTP响应报文格式:状态行+响应头+空行+消息体,状态行包括HTTP版本号、状态码、状态说明。
  4. 断开 TCP 连接(四次挥手)
    完成一次 HTTP 请求后,服务器并不是马上断开与客户端的连接。默认启用 持久连接,以便处理不久后到来的新请求,无需重新建立连接而增加慢启动开销,提高网络的吞吐能力。在反向代理软件 Nginx 中,持久连接超时时间默认值为 75 秒,如果 75 秒内没有新到达的请求,则断开与客户端的连接。同时,浏览器每隔 45 秒会向服务器发送 TCP keep-alive 探测包,来判断 TCP 连接状况,如果没有收到 ACK 应答,则主动断开与服务器的连接。
  5. 浏览器解析 HTML 代码,请求js,css等资源,最后进行页面渲染,显示出来。

DNS

浏览器输入地址,浏览器去调用gethostbyname库函数,这个函数通过网卡给DNS服务器发送UDP请求,接收结果,然后将结果返回浏览器。

为什么是UDP?因为UDP快啊!UDP协议传输内容不能超过512字节,查询域名一般返回的内容都不会超过这么多。

但DNS还是有用到TCP的,DNS有两种类型服务器,主DNS服务器和辅助DNS服务器。当一个辅助DNS服务器启动时,需要与主DNS服务器通信,并加重数据信息,称为区域传送。

为什么是TCP?因为TCP可靠,而且传送的数据可能大于512字节。

常见的状态码:

  • 1xx,表示成功发出请求正在处理
  • 2xx,表示成功处理请求
  • 3xx,表示需要完成请求,需要进行重定向
  • 4xx,表示请求错误,妨碍了服务器的处理
  • 5xx,表示服务器错误

  • 200 请求被正确处理

  • 301 资源被永久转移到另一个URL
  • 302 资源被暂时转移到另一个URL
  • 400 客户端请求有语法错误,不能被服务端识别
  • 403 服务器收到请求,但拒绝提供服务(认证失败)
  • 404 请求资源不存在
  • 500 服务器执行请求发生错误

GET和POST区别

HTTP请求方法,POST和GET都是向服务器提交数据,并且都会从服务器获取数据。

  • get通过地址栏传输,安全性较低,post通过报文传输,安全性更高一些,但也没多高,毕竟http本身就是不安全的
  • get长度受限于url长度,传输数据量小,post理论上没有限制
  • 大部分情况下,get产生一个数据包,post产生两个数据包,也意味着get效率更高

对于get请求,浏览器会把http head和 data 一起发送出去,服务器响应200,返回数据。
对于post请求,浏览器会先传http head,然后服务器响应100 continue,浏览器再发送data,服务器响应200,返回数据。

一般来说,做数据查询用get,做增删改用post(网站登陆,文件传输)。

HEAD类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头。

报文组成:

  • 对于Request:请求行,说明请求类型,要访问的资源以及HTTP版本;
  • 对于Response:状态行,状态码,状态消息。
  • 请求头,一些附加信息
  • 空行,必须有
  • 数据部分,是主体

浅谈HTTP中Get、Post、Put与Delete的区别

1、GET请求会向数据库发索取数据的请求,从而来获取信息,该请求就像数据库的select操作一样,只是用来查询一下数据,不会修改、增加数据,不会影响资源的内容,即该请求不会产生副作用。无论进行多少次操作,结果都是一样的。

2、与GET不同的是,PUT请求是向服务器端发送数据的,从而改变信息,该请求就像数据库的update操作一样,用来修改数据的内容,但是不会增加数据的种类等,也就是说无论进行多少次PUT操作,其结果并没有不同。

3、POST请求同PUT请求类似,都是向服务器端发送数据的,但是该请求会改变数据的种类等资源,就像数据库的insert操作一样,会创建新的内容。几乎目前所有的提交操作都是用POST请求的。

4、DELETE请求顾名思义,就是用来删除某一个资源的,该请求就像数据库的delete操作。

就像前面所讲的一样,既然PUT和POST操作都是向服务器端发送数据的,那么两者有什么区别呢。。。POST主要作用在一个集合资源之上的(url),而PUT主要作用在一个具体资源之上的(url/xxx),通俗一下讲就是,如URL可以在客户端确定,那么可使用PUT,否则用POST。

HTTP1.0,HTTP 1.1主要区别

HTTP1.1:

  1. HTTP1.1默认支持长连接,HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用一个长连接来发多个请求。
  2. 节约带宽,只发送header信息,如果服务器认为客户端有权请求服务器,则返回100,否则401。这样返回401就可以不用返回body,节约带宽。

cookie和session的作用和区别

Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端会把Cookie保存起来。

当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

每个用户访问服务器都会建立一个session,那服务器是怎么标识用户的唯一身份呢?事实上,用户与服务器建立连接的同时,服务器会自动为其分配一个SessionId。

区别:

  • cookie数据存放在客户的浏览器上,session数据放在服务器上。
  • session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用COOKIE
  • cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
  • 将登陆信息等重要信息存放为SESSION,其他信息如果需要保留,可以放在COOKIE中

HTTP重定向过程

301:永久性转移
302:暂时性转移
重定向过程:客户浏览器发送http请求 ——> web服务器接受后发送302状态码响应及对应新的location给客户浏览器 ——> 客户浏览器发现是302响应,则自动再发送一个新的http请求,请求url是新的location地址 -> 服务器根据此请求寻找资源并发送给客户。

HTTP和HTTPS区别

  • HTTP通信使用明文,内容可能被窃听;HTTPS是具有安全性的SSL加密传输协议
  • HTTP不验证通信方身份,因此有可能遭遇伪装;HTTPS有验证机制
  • HTTP无法验证报文的完整性,所以有可能被篡改;HTTPS有完整性保护
  • HTTP使用80端口,HTTPS使用443端口
作者

Benboby

发布于

2021-01-10

更新于

2021-03-25

许可协议

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×