计算机网络知识点
网络模型
- 物理层:物理层处于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包接受到对应的立即响应所耗费的时间
ARQ协议
停止等待ARQ:发完一个分组就停止,等待确认,超时就重发,确认收到再发送下一个分组。缺点是信道利用率低。
连续ARQ:维护一个发送窗口,分组内可用连续发送出去,接受方采用累计确认,对按序到达的最后一个发组发送确认,表明之前的已经全部收到了。
缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。
TCP流量控制
接受端缓冲区大小有限,发送的太快太多接受端来不及处理。
如果一个一个发数据段,等确认了再发下一个,效率就比较低。
滑动窗口是流量控制和核心,存在与TCP首部,TCP首部有个window字段,用于接受端告诉发送端自己还有多少缓冲区可以接收数据。
当window字段为0,就会停止发送数据。那什么时候可以继续发送数据?
一种可能是接收方去发一个报文去通知发送端可以继续发,但要是这个报文丢了,就会再次陷入僵局。
因此采取的策略当收到win=0的报文后,就开启一个计时器,每隔一段时间就发个测试报文测试一下,打听一下是否可以发数据了。
TCP拥塞控制
防止发送方发的太快,使得网络来不及处理,从而导致网络拥塞。
- 慢开始:设置拥塞窗口cwnd为1,然后以指数增长(乘2),逐步发送数据。
- 拥塞避免:为了防止cwnd增加过快而导致网络拥塞,所以需要设置一个慢开始门限ssthresh状态变量,窗口大小增长到门限值,就改为执行拥塞避免算法,每经历过一次往返时间就使cwnd增加1。
- 快速重传:累计收到三个同样的确认报文,说明下一个报文还没有到达,认为拥塞发生了,立即重传该报文。
- 快速恢复:将当前窗口大小和门限值调整为当前窗口的一半,开始执行拥塞避免算法。
流量控制和拥塞控制的区别:
- 一个是丢包在接受端上,一个是丢包在路由器上。
- 一个是怕接受端来不及处理,一个怕网络拥塞,网络来不及处理
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到页面加载发生了什么?
- DNS 域名解析
当你输入了 www.google.com 并按下回车后,浏览器检查输入框,发现不是 ip 地址,于是去 浏览器缓存 里面找有没有相关记录,发现没有,那就继续去 系统缓存 找,也就是系统中的 hosts 文件,还是没有,又继续去 路由器缓存 里面找,查看的是路由器映射表。接着,计算机将域名发送给 本地DNS服务器,也就是 提供本地连接的服务商,本地DNS服务器找不到的话,会将域名发送到 根域名服务器,也就是 ‘.’,找不到就返回 顶级域名服务器 —— .com 的IP地址,再请求 顶级域名服务器IP 返回 二级域名服务器 —— google.com 的IP地址…直到找到对应的IP地址,然后返回给浏览器。 - 发起 TCP 连接(三次握手)
知道IP地址后,传输层的TCP协议就可以向远端服务器发起连接请求了。 - 发送 HTTP 请求,接受 HTTP 响应
连接上了,可以传输了。计算机需要将用户输入的地址封装成 HTTP Request 请求报文,发送到服务器,服务器收到请求后会发出应答,即响应数据。
HTTP请求报文格式:请求行+请求头+空行+消息体,请求行包括请求方式(GET/POST/DELETE/PUT)、请求资源路径(URL)、HTTP版本号。
HTTP响应报文格式:状态行+响应头+空行+消息体,状态行包括HTTP版本号、状态码、状态说明。 - 断开 TCP 连接(四次挥手)
完成一次 HTTP 请求后,服务器并不是马上断开与客户端的连接。默认启用 持久连接,以便处理不久后到来的新请求,无需重新建立连接而增加慢启动开销,提高网络的吞吐能力。在反向代理软件 Nginx 中,持久连接超时时间默认值为 75 秒,如果 75 秒内没有新到达的请求,则断开与客户端的连接。同时,浏览器每隔 45 秒会向服务器发送 TCP keep-alive 探测包,来判断 TCP 连接状况,如果没有收到 ACK 应答,则主动断开与服务器的连接。 - 浏览器解析 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:
- HTTP1.1默认支持长连接,HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用一个长连接来发多个请求。
- 节约带宽,只发送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端口