网络相关面试知识点汇总
OSI七层模型
- 物理层：网卡，网线，集线器，中继器，调制解调器
- 数据链路层：网桥，交换机
- 网络层：路由器
- 网关工作在第四层传输层及其以上
https://blog.csdn.net/yaopeng_2005/article/details/7064869
三次握手和四次挥手
三次握手
三次握手：建立TCP连接
- 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
（server（接收端） 确认对方发送正常） - 服务端–发送带有 SYN + ACK 标志的数据包–二次握手–客户端
（Client（发送端）确认自己发送、接收正常，对方发送正常；Server确认自己接收正常，对方发送正常） - 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端
（自己、对方的发送、接收均正常）
为什么不是四次握手？
发送方与接收方都会有自己的 ISN （下面的例子中就是 X 与 Y）来做双方互发通信，具体的描述如下：
- A --> B SYN my sequence number is X
- A <-- B ACK your sequence number is X
- A <-- B SYN my sequence number is Y
- A --> B ACK your sequence number is Y
2与3都是 B 发送给 A，因此可以合并在一起，因此成为three way (or three message) handshake
为什么不是两次握手？
假设不确认 SYN 中的 SEQ (4)，只有B确认了收到了 A 的 SEQ， A 无法确认收到 B 的。也就是说，只有 A 发送给 B 的包都是可靠的， 而 B 发送给 A 的则不是，所以这不是可靠的连接。
四次挥手
四次挥手：断开TCP连接
中断连接端可以是Client端，也可以是Server端
TCP是全双工的，断开连接时，两端都需要发送FIN和ACK
- client - 发送一个
FIN，用来关闭client到server的数据传送
server收到FIN，知道“client没有数据要给我了”
- server - 数据都发送完成，发回一 个
ACK，确认序号为收到的序号加1 。和 SYN 一样一个 FIN 将占用一个序号
server收到了FIN，但是我还有数据要发送，就不必着急关闭socket，所以先发送ACK，告诉client “你的请求我收到了，但我还没准备好断开，请继续等我的消息”。
Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。
- server - 关闭与client的连接，发送一个
FIN给客户端
当Server端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。
Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。
- client - 发回
ACK报文确认，并将确认序号设置为收到序号加1
Server端收到ACK后，“就知道可以断开连接了”。
Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！
相关问题
为什么TCP连接的时候是三次握手，关闭的时候却是四次握手？
第二次握手，server收到client的SYN后，可以直接发送SYN + ACK报文
关闭连接时，server收到FIN后，有可能不会立即关闭socket，只能先回复一个ACK，等server的所有报文都发送完成，再发送FIN，所以这两步不能合二为一（要等server发送完成）。
syn攻击的原理和防范
三次握手中，server在发送SYN-ACK之后，收到client ACK之前，此时的TCP连接是半连接状态（half-open connect），server处于Syn_RECV状态，如果收到ACK，那么server转为established状态
Syn攻击：短时间伪造大量不存在的IP地址，向server发送syn包。server回复ACK并等待client的ACK。由于IP不存在，server不断重发直至超时，伪造的SYN包长时间占用未连接队列 --> 正常的SYN请求被丢弃，目标系统运行缓慢
防范：server看到大量半连接状态，尤其是IP随机。Linux命令检测是否被Syn攻击：
netstat -n -p TCP | grep SYN_RECV
打开一个网页，整个过程会使用哪些协议
DNS
域名和IP地址相互映射的一个分布式数据库。
域名：www.csdn.com
IP： 47.95.164.112
TCP UDP
传输层协议
区别
TCP和UDP的区别和优缺点
区别：
-
TCP面向
连接（如打电话要先拨号建立连接）; UDP是无连接 的，即发送数据之前不需要建立连接 -
TCP提供
可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
-
UDP具有较好的
实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。 -
每一条TCP连接只能是
点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信 -
TCP对
系统资源要求较多，UDP对系统资源要求较少。
TCP：
面向连接
UDP：
面向报文
一个非连接的协议，传输数据之前源端和终端不建立连接， 当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。
在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了。UDP传送数据的速度仅仅是受应用程序生成数据的速度、 计算机的能力和传输带宽的限制；
在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作。UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
TCP
-
可靠
TCP 的可靠连接是靠 seq（ sequence numbers 序列号）来达成的。通过TCP 连接发送的每一个包，都有一个sequence number。而因为每个包都是有序列号的，所以都能被确认收到这些包。确认机制是累计的，所以一个对sequence number X 的确认，意味着 X 序列号之前(不包括 X) 包都是被确认接收到的。 -
ARQ
自动重传请求（Automatic Repeat-reQuest)
- 停止等待ARQ协议
超时重传，确认丢失和确认延迟 - 连续ARQ协议
连续（流水线传输）发送一组数据包，然后再等待这些数据包的ACK。
连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口（位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率）
- 滑动窗口协议
规则：
（1）凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。
（2）只有当发送方A收到了接收方的确认报文段时，发送方窗口才可以向前滑动几个序号。
（3）当发送方A发送的数据经过一段时间没有收到确认（由超时计时器控制），就要使用回退N步协议，回到最后接收到确认号的地方，重新发送这部分数据。
UDP实现可靠性
如何让 UDP 保证其可靠性
模拟tcp的可靠机制来实现,保证四个无即可（无丢失、无失序、无错误、无重复）
- 发送方每次发出的数据进行编号，同时保持顺序的正确。seq
- 每次接收方接收到数据，发出应答信号。同时发送方在规定的时间检测是否接收到应答，如果没有接收到应答，重发，三次后还未收到应答直接判断发送失败。超时重传
- 发送数据时，发送方增加校验位。如果接收方校验出错，请求重发。出错重传
RUDP
Reliable UDP
提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为
RTP
Realtime Transportation Protocol
为数据提供了具有实时特征的端对端传送服务.RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。
UDT
UDP-basedData Transfer Protocol
是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议 TCP 在高带宽长距离网络上性能很差。UDT 建于 UDP 之上，并引入新的拥塞控制和数据可靠性控制机制。UDT 是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于 UDT 完全在 UDP 上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
TCP的拥塞控制
- 慢开始（slow start）
- 初始 cwnd = 1 MSS
- 一个RTT（round trip time 接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报），cwnd = cwnd * 2 （可以连续发两个数据报，发四个，发八个……）
- 当cwnd = 慢开始门限值，开始拥塞避免方法
- 拥塞避免
- 一个RTT，cwnd = cwnd + 1
如果出现loss，门限值变为一半；cwnd = 1 重新初始化
- 快速重传
- 快速恢复
门限值 变一半； cwnd 变一半。然后开始拥塞避免算法
HTTP
超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应，定义了web客户想web服务器请求页面的方式以及服务器想客户传送web页面的方式
HTTPS
HTTP明文传输，使用HTTPS进行加密
HTTPS特点
- 内容加密传输
- 身份认证（保证访问指定服务）
- 数据完整（防止第三方篡改）
HTTPS流程：
- client发起https请求，将自身的Cipher Suite密钥算法套件发给server
- server存在一些公钥和私钥
- server收到client的所有cipher后和自身支持的对比。不支持，断开连接。支持，从中选择一中加密算法以证书的形式返回给client
HTTP与cookie
无状态协议： HTTP不保存关于客户的任何信息
用cookie来完成用户和服务器的交互
cookie的四个组件：
- HTTP相应报文中的cookie首部行
- HTTP请求报文中的cookie首部行
- 用户浏览器保存管理的cookie文件
- web站点的后端数据库
HTTP报文格式
请求报文
请求行（request line）：报文的第一行。GET, POST, PUT, HEAD, DELETE
首部行（header line）：第一行以外的（Host，Connection，User-agent …）
报文主体
响应报文
初始行（status line）：HTTP/1.1 200 OK 使用的HTTP版本 + 状态码
首部行（header line）：
报文主体（entity body）
HTTP状态码
- 200 OK 请求处理成功，返回相关信息
- 204 No Content 请求处理成功，但响应报文没有主题返回
- 206 Partial Content 客户端进行了范围请求，服务器成功执行请求并返回指定范围的实体内容
- 301 Moved Permanently 永久性重定向。请求的资源已经被分配到新的url
- 302 Found 临时性重定向
- 304 Not Modified 客户端发送附带条件的请求后，服务器允许请求，但内容并没修改，返回304。即客户端可以使用缓存的内容
- 400 Bad Request 请求报文存在语法错误。需要修正请求报文后再次发送请求
- 403 Forbidden 请求资源的访问被服务器拒绝。服务器没必要给出拒绝的理由。
- 404 Not Found 服务器上无法找到被请求的资源
- 500 Internet Server Error 服务器在执行请求时发生了错误。可能是Web应用存在的 bug 或者临时的障碍
- 503 Service Unavailable 服务器处于超载或者故障状态。如果事先得知何时可以解决故障，可以将时间写入Retry-after首部字段再返回给客户端。
GET&HEAD PUT&POST
GET 从服务器上获取资源
HEAD 跟GET功能类似，但是报文中不返回文件主体（只返回到head line）。用于检查文件，而不是真的获取文件内容
POST 用于提交请求，可以更新或者创建资源，是非幂等的，举个例子：在用户注册功能上，每次提交都是创建一个用户账号，这个时候就用POST。目的在于提交数据并用于服务器端的存储，而不允许用户过多的更改相应数据
PUT用于向指定URL传送更新资源，是幂等的。每次请求都只是覆盖原先的值，当操作没有达到预期的目标时，我们可以不停的重试，而不会对资源产生副作用。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
