计算机网络
https://www.nowcoder.com/discuss/643130?type=all&order=time&pos=&page=1&ncTraceId=&channel=-1&source_id=search_all_nctrack
1.TCP相关
TCP报头20个字节,也就是160个比特位。其中包括前5行的内容。
-
16位的源端口号加上16位的目的端口号,这两个值加上IP首部中的源端IP地址和目的端IP地址,用于多路复用或多路分解来自或送至上层应用的数据。
-
32位的序列号,其用来标识从TCP发送方向TCP接收端发送的数据字节流,它表示该报文段首字节的字节流编号。
-
32位的确认序号标识发送确认一段所期望收到的下一个序号。序号字段和确认号字段用于TCP发送方和接收方来实现可靠数据传输服务。
-
4比特的首部长度指示了以32比特为单位的TCP的首部长度。一般TCP首部长度为20字节,则该字段为0110。
-
6位作为保留字段。
-
6比特的标志字段。URG比特用来指示报文段存在着被发送方的上层实体置为“紧急”的数据。ACK比特用于指示确认字段中的值是有效的。RST, SYN, FIN用于连接的建立和拆除。PSH比特指示接受方应立即将数据交给上层。
-
16位的接收窗口字段,该字段指示接收方愿意接受的字节数量,用于流量控制。
-
16位校验和。
-
16位紧急数据指针为紧急数据的最后一个字节。
TCP可靠的传输机制
**💛**三次握手建立连接
**💛**四次挥手断开连接
**💛**连续ARQ:有一个发送窗口,窗口内的分组(如:5组)可以连续发出去而不需要等待,没收到一个确认,就把窗口向前滑动一个窗口的位置(如:现在发送第6组)。接收方也不是一个个确认,对按序到达的最后一个分组发送确认,如果发送方收到这个信息,就表明前几个都被正确接受了(提高了信道利用率和传输效率)**Go-back-N(回退N)**机制,如果前2组确认收到了,后3个没有下落,就得把后3个都重传。
**💛**拥塞控制
- 流量控制,控制发送端的发送速率
- 拥塞控制,慢启动,拥塞避免算法,快重传、快恢复
TCP和UDP的区别
① TCP 是面向连接的,发送数据前必须先建立连接,发送某些预备报文段;UDP 无连接,发送数据前不需要建立连接。
② TCP 连接是点对点的,只能是单个发送方和单个接收方之间的连接;UDP 支持一对一、一对多和多对多通信。
③ TCP 提供可靠的交付服务,通过 TCP 传送的数据无差错、不丢失、不重复,按序到达;UDP 使用尽最大努力交付,不保证可靠性,主机不需要维持复杂的连接状态。
④ TCP 是面向字节流的,TCP 不保证接收方的数据块和发送方的数据块具有对应大小的关系,但接收方的字节流必须和发送方的字节流完全一样。应用程序必须有能力识别收到的字节流,把它还原成应用层数据;UDP 面向报文,对应用层报文添加首部后就交付 IP 层。
⑤ TCP 有拥塞控制;UDP 没有拥塞控制,网络拥塞不会降低源主机的发送速率,这对某些实时应用很重要,如视频会议。
TCP三次握手
一开始:客户端 closed,服务端listen
**💛**第一次握手:客户端向服务器端发送一个SYN报文(同步报文),指明客户端的初始序列号j。客户端处于SYN_SENT状态。
**💛**第二次握手:服务端收到SYN报文后,发送确认包ACK(j+1),表示自己收到了;同时发送一个自己的SYN包,指明自己的初始序列号k。服务器端处于SYV_RECV状态。
**💛**第三次握手:客户端收到服务器端的ACK+SYN包,向服务器发送ACK包(k+1)。客户端处于established状态。
最后:服务器收到了ACK包,也处于established状态,双方建立起了连接。
Q:为什么要进行三次握手
第一次:客户端发送,服务端收到了。服务端得出结论:客户端发正常、自己收正常。
第二次:服务端回应,客户端收到了。客户端得出结论:自己之前可以正常发,服务器端可以正常接收并发送,自己还可以正常接收。
第三次:客户端回应,服务端接收。服务端得出结论:自己之前可以正常发,客户端也可以正常接收。
经过三次之后,双方都知道了自己和对方都可以正常接收和发送。
- 如果第三个ACK包丢了会怎么处理?
服务端会等待3、6、12S之后重新发送SYN+ACK的包,如果发送了指定次数之后,仍然没有收到客户端的ACK应答,服务端就会自动关闭这个连接。
- 如果第二个ACK包丢了会怎么处理?
客户端没有收到响应,以为自己的SYN丢了,触发超时重传机制,又向服务端发送了一个【SYN=1,ACK=0,SEQ=Z】;
服务器端也知道自己的包丢了,于是重传了若干次的SYN+ACK,这是他如果突然收到了客户端新的包,为了减轻SYN标志位进行的RST攻击的影响,服务端会立即发送一个【ACK=1,SEQ=Y,ACK=X+1】给客户端,用于重新连接。
客户端会立即回复【RST=1,SEQ=X+1】,表明这个RST是由于前面的ACK【ACK=1,SEQ=Y,ACK=X+1】引起的,然后,双方断开连接。
Q:SYN Flooding
客户端只进行半连接,它只发出SYN报文,不以ACK响应结束握手。服务器会一直进行第二次连接。
TCP四次挥手
一开始:双方都处于established
**💛**第一次挥手:客户端想要断开连接,给服务端发送一个FIN报文,报文中指定一个序列号j。此时客户端处于CLOSED_WAIT1状态。
**💛**第二次挥手:服务端收到客户端的FIN了,返回一个ACK,表示自己收到了,将j+1作为ACK的序列号。此时服务端处于CLOSED_WAIT2状态。
**💛**第三次挥手:服务端想断开连接了,发送一个FIN报文,报文中指定了一个序列号q。此时服务端处于LAST_ACK状态。
**💛**第四次挥手:客户端收到了服务端的FIN,返回一个ACK,表示自己收到了,将q+1作为ACK的序列号。此时客户端不会直接关闭,它处于TIME_WAIT状态,它会等一段时间,确保服务端收到自己的报文,然后转为CLOSED状态。
最后:服务端收到了客户端的回复,连接整个就关闭了,它也变成了CLOSED状态。
Q:为什么不能两次挥手完毕,客户端就断开?–>服务端可能还有信息没有发送完
三次握手、四次挥手常见问题:tcp 三次握手,四次挥手几常见面试题 - kingle-l - 博客园 (cnblogs.com)
为什么TCP四次挥手中,客户端需要在Time-Waited状态等待2MSL?
- 保证最后发送的ACK报文一定会被对方接受,重发可能丢失的ACK报文。(保证可以处理一定的报文丢失问题)
- 关闭链接一段时间内可能会出现相同的IP地址和端口建立新的连接,为了防止就连接的重复分组在新连接已经终止后再见,2MSL的等待足够让最多存活msl被丢弃。(等待的时间足够清理现有的通信数据)
流量控制
接收端在接收到发送端的数据口进行处理,会将数据放入接收缓存中进行处理。如果发送端的发送速度太快,导致接收端的缓冲区很快就被填满了,如果此时发送端依旧不知好歹发送数据,那么接下来的数据都会丢失,继而导致丢包的一系列的连锁反应。因此,TCP根据接收端的数据处理能力,决定发送端的发送速度,这就是流量控制。
在TCP协议的报文头中,有一个16位字段的窗口大小。窗口大小表示接收端接收数据的缓冲区的大小。这个数字越大,证明接受端接收缓冲区的剩余空间就越大,网络的吞吐量就越大。接收端会在确认应答发送ACK报文时,将自己的即时窗口大小填入,并随着ACK保卫发送过去。发送方根据窗口的大小改变自己的发送速度。如果收到窗口大小的值为0,那么发送方将停止发送数据,并定期向接收端发送窗口探测报文,让接收端把现有的窗口大小发送给客户端。
拥塞控制
什么是拥塞控制(可以理解,在没有红绿等的十字路口,很容易发生轻微堵车,如果这种问题得不到缓解,那么可能会直接导致十字路口处于死锁状态,任何人都无法通过):
- 在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就会变坏。这种情况下就叫做拥塞。
- 在计算机网络中的链路容量,减缓节点中的缓存和处理及等,都是网络的资源
- 若出现拥塞而不进行控制,这个网络的吞吐量将随着输入负荷的增大而下降
网络中对资源的需求超过可用量的情况就叫拥塞,当吞吐量明显小于理想吞吐量时就出现了轻度拥塞。拥塞控制就是减少注入网络的数据,减轻路由器和链路的负担,这是一个全局性问题,涉及网络中的所有路由器和主机,而流量控制是一个端到端的问题。
TCP 的拥塞控制算法包括了慢启动、拥塞避免和快恢复。慢启动和拥塞避免是 TCP 的强制部分,差异在于对收到的 ACK 做出反应时拥塞窗口增加的方式,慢启动比拥塞避免增加得更快。快恢复是推荐部分,对 TCP 发送方不是必须的。
-
慢启动:拥塞窗口 cwnd 以一个 MSS 最大报文段开始,每当传输的报文段首次被确认就增加一个 MSS。因此每经过一个 RTT 往返时间,拥塞窗口就会翻倍,发送速率也会翻倍(慢启动的慢要理解正确)。结束慢启动的情况:
- ① 发生超时事件,发送方将 cwnd 设为 1,重新开始慢启动,并将慢启动阈值设置为 cwnd/2。
- ② 当拥塞窗口达到慢启动阈值时就结束慢启动而进入拥塞避免模式。
- ③ 如果检测到三个冗余的 ACK,TCP 就会执行快重传并进入快恢复状态。
-
拥塞避免:一旦进入拥塞避免状态,cwnd 值大约是上次拥塞时的 1/2,距离拥塞并不遥远。因此 TCP 不会每经过一个 RTT 就将 cwnd 翻倍,而是较为保守地在每个 RTT 后将 cwnd 加 1。发生超时事件时,拥塞避免和慢启动一样,将 cwnd 设为 1,并将慢启动阈值设置为 cwnd/2。
-
快恢复:有时个别报文段丢失,但网络中并没有出现拥塞,如果使用慢启动会降低传输效率。这时应该使用快重传来让发送方尽早知道出现了个别分组的丢失,快重传要求接收端不要等待自己发送数据时再捎带确认,而是要立即发送确认。即使收到了乱序的报文段也要立即发出对已收到报文段的重复确认。当发送方连续收到三个冗余 ACK 后就知道出现了报文段丢失的情况,会立即重传并进入快恢复状态。在快恢复中,会调整慢启动阈值为 cwnd/2,并进入拥塞避免状态。
滑动窗口怎么变化的?
滑动窗口的长度取决于接收方对于接收数据的能力。
滑动窗口以字节为单位。发送端有一个发送窗口,窗口中的序号是允许发送的序号,窗口的后沿是已发送且确认的序号,窗口的前沿是不允许发送的序号。窗口的后沿可能不动(没有收到新的确认),也有可能前移(收到了新的确认),但不会后移(不可能撤销已经确认的数据)。窗口的前沿一般是向前的,可能不动(没有收到新的请求或对方的接收窗口变小),也可能收缩(TCP 强烈不建议这么做,因为发送端在收到通知前可能已经发送了很多数据,将产生错误)。
2.HTTP相关
HTTP和HTTPS的区别
https://mp.weixin.qq.com/s/21JaXwdfSjItj5SgOwhapg
**💛**HTTP是一种超文本传输协议,目的是确保客户端和服务端之间的通信。
HTTP协议由HTTP请求和HTTP响应组成。
缺点:
HTTP报文使用明文的方式传送,容易被窃听;
HTTP的请求和响应不会通信方的身份进行认证,可能遭遇伪装;(任何人都可以欺诈用户)
HTTP协议无法证明通信内容的完整性,接收到的内容可能被篡改。
**💛**HTTPS = HTTP+加密(对称加密,AES/DES/RC4)+认证(非对称加密RSA/ECC/DH)+完整性保护(散列算法 MD5/SHA)
HTTPS通过SSL证书验证通信双方的身份,并为浏览器和服务器之间的通信进行加密。
缺点:
除了和TCP连接,发送HTTP请求外,还要与SSL通信,再由SSL与TCP通信。因此通信慢。
SSL会进行加密处理,在服务端和客户端都要进行解密-解密的处理,消耗了更多的硬件资源。
申请SSL证书需要费用。
**💛**总结二者的区别:
https更安全,对搜索引擎更友好,浏览器会优先搜索https网页
https需要SSL证书,http不需要
https的端口443,http的端口80
https会在浏览器中显示安全锁,http不会
https://blog.csdn.net/howgod/article/details/89596638
SSL建立连接的过程(TLS)
- 客户端向服务器的443端口,发送随机数1和客户端支持的加密算法表
- 服务器收到消息后相应,包括随机数2和加密算法表中的具体加密算法
- 服务器端香客户端发送数字证书CA
- 客户端解析证书,验证正确性,用随机数1、2和预主密钥组成会话密钥,并用CA证书的公钥加密
- 服务器端得到信息,用自己的私钥解密后得到对应的会话密钥
- 客户端利用会话密钥发送信息给服务端,验证服务端
- 服务端也会通过会话密钥回传信息给服务端
HTTP请求和响应
**💛**请求:
请求报文的格式:
请求行:请求方式post/get+请求的资源+协议版本
请求头:客户端给服务端发送的一些东西,如客户端浏览器相关信息等,一般是键值对
请求头和请求体中间用空行作分隔
请求体:get方法没有携带数据,当请求方式是post的时,请求体有请求的参数
*能看到请求体,提交方式就是post,看不到就是get;get的请求数据在请求行中;
*判断客户端是什么浏览器,看http请求头User-Agent里的浏览器:MSIE,FireFox等
**💛**响应:
响应行:协议的版本+状态码+状态描述的信息
响应头:服务器端将信息以键值对的形式返回给客户端,如服务器的压缩格式
响应头和响应体中间空行作分隔
响应体:响应体是服务器回写给客户端的页面正文,浏览器将正文加载到内存,然后解析渲染,显示页面内容
GET和POST请求的区别
**HTTP的底层是TCP/IP。**所以GET和POST的底层也是TCP/IP,也就是说,GET/POST都是TCP链接。GET和POST能做的事情是一样的。
**💛**最大的区别是,请求带参数时,报文格式不同,GET方法的参数放在URL中,POST方法的参数放在请求体中。
不带参数的请求,没有区别。
因此,Get是不安全的,因为在传输过程,数据被放在请求的URL中;Post的所有操作对用户来说都是不可见的。
post: username=zhangsan&password=123
url: http://localhost:8080…?username=zhangsan&password=123
**💛**Get传送的数据量较小,这主要是因为受URL长度限制;Post传送的数据量较大,一般被默认为不受限制。
限制单次运输量来控制风险,数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是,**(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。**超过的部分,恕不处理。如果你用GET服务,在request body偷偷藏了数据,不同服务器的处理方式也是不同的,有些服务器会帮你卸货,读出数据,有些服务器直接忽略,所以,虽然GET可以带request body,也不能保证一定能被接收到哦。
**💛**GET和POST还有一个重大区别,简单的说:GET产生一个TCP数据包;POST产生两个TCP数据包。具体来说,对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
另外, 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。
二者区别还包括一些,请求的参数是否保存、参数的数据类型、编码的方式不同等等。
常见状态码
状态码 | 状态码英文名称 | 中文描述 |
---|---|---|
100 | Continue | 继续。客户端应继续其请求 |
101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议 |
200 | OK | 请求成功。一般用于GET与POST请求 |
201 | Created | 已创建。成功请求并创建了新的资源 |
202 | Accepted | 已接受。已经接受请求,但未处理完成 |
203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本 |
204 | No Content | 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档 |
205 | Reset Content | 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域 |
206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
状态码 | 状态码英文名称 | 中文描述 |
---|---|---|
300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择 |
301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
306 | Unused | 已经被废弃的HTTP状态码 |
307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
2××成功
200 OK
客户端发来的请求在服务器端被正常处理了。
204 No Content
请求已成功处理,但无资源返回。
3××重定向
301 Moved Parmanently永久性重定向
请求的资源已被分配了新的URL。
302 Found临时重定向
请求的资源被临时定位到新的URL。
304 NotModified 客户端已有缓存
当一个客户端(通常是浏览器)向web服务器发送一个请求,如果web服务器返回304响应,则表示此请求的本地缓存是最新的,可以直接使用。这种方法可以节省带宽,避免重复响应。
判断:Last-Modified最后修改时间与If-Modified-Since上一次的修改时间 作比较,一样就是没修改;If-Modified-Since比Last-Modified时间早,就是修改过了。
4××客户端错误
400 Bad Request
请求报文中存在语法错误,需要修改请求的内容; (比如URL过长,不同浏览器和服务器的限制不一样,Google8182字节,IE浏览器2048字节,apache能接受url长度限制为8192字节)
404 Not Found
服务器上没有找到请求的资源。 (客户端错误的请求了不存在的资源)
5××服务器错误
500 服务器内部在执行请求时发生了错误;
503服务器停机或者正在维护。
长连接和短连接
-
短连接:是在数据传送过程中,只在需要发送数据时,才去建立一个连接,数据发送完成后,则断开此连接,即每次连接只完成一项业务的发送。连接–传数据–断开
-
长连接:指在一个连接上可以连续发送多个数据包,在连接保持期间,如果没有数据包发送,需要双方发链路检测包。连接–传数据–保持连接–传数据--------一方关闭连接。
保持连接节省了为每个请求建立新连接所需要的时间,还节约了带宽。对于服务端来说会耗费一定的资源,安全性较差。
应用场景:
-
长连接适用于操作频繁,点对点的通信,如数据库的连接。
-
web网站的http服务一般用短连接,并发量大。
HTTP1.1和HTTP1.0相比较而言,最大的区别就是增加了持久连接支持(貌似最新的HTTP1.1 可以显示的指定 keep-alive),但还是无状态的,或者说是不可以信任的。
实现:
- 长连接:在首部字段中设置Connection:keep-alive和keep-alive:timeout=60
- 短连接:connection:close
HTTP 1.0
短连接:每次发送请求都要重新建立tcp请求,即三次握手,非常浪费性能
无host头域,也就是http请求头里的host,
不允许断点续传,而且不能只传输对象的一部分,要求传输整个对象
HTTP 1.1
长连接,流水线,使用connection:keep-alive使用长连接,与http 2.0不同的是,
host头域
由于长连接会给服务器造成压力
HTTP 2.0
头部压缩,双方各自维护一个header的索引表,使得不需要直接发送值,通过发送key缩减头部大小
多路复用,使用多个stream,每个stream又分帧传输,使得一个tcp连接能够处理多个http请求
可以使用服务端推送
HTTP 3.0
基于google的QUIC协议,而quic协议是使用udp实现的
减少了tcp三次握手时间,以及tls握手时间
解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题
优化了重传策略,重传包和原包的编号不同,降低后续重传计算的消耗
连接迁移,不再用tcp四元组确定一个连接,而是用一个64位随机数来确定这个连接
更合适的流量控制
3.DNS解析
DNS:域名系统,将域名和IP地址的映射保存在一个分布式的数据库中。
将网址输入浏览器。
**💛**浏览器查找自己的缓存。(没有就下一步,有就返回ip)
**💛**操作系统查找自己的缓存。
**💛**查找本地的host文件。
**💛**查找本地的dns服务器,(ip为114.114.114.114),本地服务器查询缓存。
💛查找后缀根域名服务器(13个),根域名服务器返回.com的顶级服务器ip。
💛本地的dns服务器去查找.com的顶级服务器,顶级服务器返回负责该域名的权威服务器ip。
💛本地的dns服务器去查找负责该域名的权威服务器,负责该域名的权威服务器返回真正的ip。
解析完成。
- 客户机—本地DNS:递归查询
- DNS服务器—DNS服务器:迭代查询
Q:为什么最后要分层去找?
使用分布式的层次数据库模式以及缓存方法来解决单点集中式的问题。
单点集中的问题:单点故障、通信容量、远距离时间延迟、维护开销大
DNS原理及其解析过程 - 极客小乌龟 - 博客园 (cnblogs.com)
4.URL相关
URL和URI的区别
URI(Uniform Resource Identifier) 统一资源标识符
URL(Uniform Resource Locator) 统一资源定位符 (常说的网页地址)
URI用字符串标识某一互联网资源,而URL表示资源的位置,URL是URI的子集。
从URL输入到页面的展现到底发生了什么(一次完整的http请求过程)
https://blog.csdn.net/qq_40804005/article/details/82876209
💛从浏览器输入网址后,经过DNS解析得到服务器的ip地址。(浏览器并不能通过域名直接找到服务器,而是通过IP地址找到对应的服务器)
💛找到服务器之后,建立TCP连接,确认客户端和服务端的序列号和确认号,并交换TCP窗口大小的信息。
💛TCP三次握手结束之后,发送HTTP请求。
-
客户端发送请求行,
-
再发送请求头信息,发送完header之后会接着发送一个空白行,
-
get请求没有数据,post请求要发送请求体。
💛服务器处理请求,返回HTTP响应报文。
-
客户端发送响应行,
-
再发送响应头,并发送一个空行,
-
最后发送响应体。
**💛**浏览器得到响应文本HTML之后,开始解析渲染。
**💛**数据传输完成之后,TCP断开连接。
5.OSI参考模型
七层,从低到高依次是:
**💛**物理层:建立、维护、断开物理连接。
**💛**数据链路层:将比特组合成字节在组合成帧,用MAC地址访问介质,发现错误但是不能改。建立逻辑连接,进行硬件地址寻址,差错校验等。
**💛**网络层:IP协议等,进行逻辑地址寻址
**💛**传输层:TCP UDP,定义传输数据的协议端口号,流控和差错控制
**💛**会话层:对应主机的进程,建立、管理、终止会话
**💛**表示层:JPEG/ASCLL等,数据的表示、安全和压缩
**💛**应用层:HTTP80/HTTPS443/FTP20-21/SSH22/SMTP25/DNS53/TFTP69,网络服务与用户的一个接口。
把通信的过程比喻为寄快递:
发快递的过程(http,应用层),你向顺丰下单(第一次请求),顺丰接单(应答),你向手机小伙联系(回应应答),你将消息放进盒子里(开始封装请求,会话层),快递员封装一层盒子贴上快递单带回网店(传输层),到快递点检查是否区域快件(网络层),将快件交给运输车(链路层),各个快递转运中心(物理层),快件到达收件市转运中心(物理层),转运输车(链路层),到达区域分发(网络层),网点派送(传输层),快递员方面签收(会话层),拆开检查(表示层),收到快递(应用层)。
转发器:物理层
网桥:数据链路层,根据mac地址决定转发
路由器:网络层,根据ip地址决定转发
网关:传输层,根据端口号决定转发
TCP/IP参考模型:网络接口层、网络层、传输层、应用层
五层模型:物理层、数据链路层、网络层、传输层、应用层
层级模型 | 常见设备 | 常见协议 |
---|---|---|
物理层 | 中继器、网线、集线器 | |
链路层 | 网卡、网桥、二层交换机 | ARP,RARP |
网络层 | 路由器、防火墙、多层交换机 | IP |
传输层 | TCP、UDP | |
会话层 | SSL | |
表示层 | ||
应用层 | FTP、HTTP、SNMP、POP3、TFTP、HTTPS |
ARP和RARP在OSI模型中属于第二层数据链路层,在TCP/IP四层模型中属于网络层
6.场景问答
服务器连不上网,怎么排查?
-
ping服务器的ip,查看本地到服务器的网络是否通畅。服务器的防火墙可能会限制ping命令,尝试第二种。
-
tcping命令进行端口ping测试,命令格式为 tcping IP 端口
-
重启下本地计算机网络。可能是频繁操作访问服务器,触发了服务器上安全软件防火墙的拦截规则,拦截了本地IP,此时重启计算机,当IP地址发生变化之后,不在黑名单里面就可以访问。
-
查看防火墙状态,是否是安全策略阻挡了访问
在弱网情况下发送请求会怎么样?
难以接入网络、丢包、超时、连接中断
7、Cookies和Session的区别
-
Cookies是由服务器生成然后再第一次连接的时候包含再响应头中发送给客户端并保存在客户端本地(Cookies主要终于认证访问者的信息,便于进行信息交互)
-
cookie 只能存储 ASCII 码,而 session 可以存储任何类型的数据。
-
session 存储在服务器,而 cookie 存储在客户浏览器中,容易被恶意查看。。
-
session 的运行依赖 session id,而 session id 存在 cookie 中,叫做 JSESSIONID。如果浏览器禁用了 cookie ,同时 session 也会失效(可以通过其它方式实现,比如在 url 中传递 session_id)。