网站建设风格定位,福田网站建设标准数据,网站开发php js,哈尔滨公司网站建设多少钱layout: post title: 八股总结#xff08;二#xff09;计算机网络与网络编程 description: 八股总结#xff08;二#xff09;计算机网络与网络编程 tag: 八股总结 文章目录计算机网络网络模型网络体系结构在浏览器输入一个网址后回车#xff0c;背后都发生了什么#x…
layout: post title: 八股总结二计算机网络与网络编程 description: 八股总结二计算机网络与网络编程 tag: 八股总结 文章目录计算机网络网络模型网络体系结构在浏览器输入一个网址后回车背后都发生了什么数据链路层地址解析ARPaddress resolution protocol协议网络层网际控制报文协议ICMPinternet control message protocol传输层TCP协议什么是TCP协议什么是TCP粘包/拆包发生的原因解决方法TCP和UDP的区别TCP和UDP的应用场景为什么TCP有「首部⻓度」字段UDP没有TCP报文结构TCP建立连接为什么是3次握手而不是2次或者4次SYN攻击DDOS攻击原理及避免方法TCP连接4挥手断开连接TCP重传机制TCP滑动窗口流量控制拥塞控制UDP协议应用层HTTPHTTP状态码GET和POST的区别HTTP和HTTPS的区别HTTPS解决了HTTP哪些问题是怎么解决的SLL/TLS协议基本流程HTTP/1.1、HTTP/2、HTTP/3演变域名解析协议DNSDomain Name System为什么域名解析用UDP协议动态主机配置协议DHCPDynamic Host Configuration ProtocolLinux网络编程TCP的socket编程计算机网络
网络模型
网络体系结构
OSI七层模型是法律上规定的国际标准但TCP/IP体系占据了市场是实际上的国际标准为了方便理解由将TCP/IP四层的结构中的网络接口层分为了物理层和数据链路层。
物理层的数据为比特流数据链路层为帧网络层为包传输层为数据段。各层常用的网络协议有哪些 数据链路层ARP地址解析协议网络层IP协议、ICMP网际控制报文协议、VPN、内部网关协议如路由信息协议RIP、外部网关协议如边界网关协议BGP传输层TCP传输控制协议、UDP用户数据报协议应用层DNS域名解析FTP文件传输DHCP动态主机配置协议HTTP超文本传输协议
网络协议栈数据报文发送与接收过程中的变化 在浏览器输入一个网址后回车背后都发生了什么
查看浏览器缓存如果没有向DNS服务器发送DNS请求采用的是UDP协议查询本地DNS服务器。如果本地DNS查不到就从根域名服务器递归的查询每一级域名服务器直到查到为止。有了DNS解析结果我们就有了服务器的ip地址以及默认的端口号了http默认端口号是80https默认端口号443。
数据链路层
通俗来讲数据链路层完成的是从目的主机所在路由器目的MAC地址到本地路由器源MAC地址的连接。
地址解析ARPaddress resolution protocol协议
ARP地址解析协议只能在单个数据链路段中使用用于将IP地址解析为对应的MAC地址。
网络层
通俗来讲网络层完成目的主机和本地主机之间的连接。
网络层最常用的就是IP协议Internet protocol将传输层的报文作为数据部分再加上IP包头组装成IP报文如果IP报文超过MTU以太网中一般为1500字节就会再次进行分片得到一个即将发送到网络的IP报文。
IP 地址分成两种意义 ⼀个是⽹络号负责标识该 IP 地址是属于哪个⼦⽹的 ⼀个是主机号负责标识同⼀⼦⽹下的不同主机。
网际控制报文协议ICMPinternet control message protocol
为了有效转发IP数据报和提高交付成功的机会网际层使用了网际控制报文协议ICMP使得主机和路由器可以使用ICMP来发送差错报告报文 和 询问报文ICMP报文被封装在IP数据报中发送。 ICMP差错报文分为以下5种
传输层
网络层已经解决了主机与主机之间的通信而传输层要解决的是两个主机各自进程间进行通信的问题。
TCP协议
什么是TCP协议
TCP是面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接一定是一对一才能连接不像UDP协议可以一台主机同时向多个主机发送消息。也就是说TCP只能一对一不能像UDP那样一对多。可靠的无论网络链路中出现怎样的链路变化TCP都可以保证一个报文一定能够到达接收端字节流消息是无边界的所以无论我们的消息有多大都可以进行传输而且消息是有序的当前一个没有收到的时候即使它先收到了后边的字节那么也不能扔给应用层去处理同时对重复的报文会自动丢弃。
什么是TCP粘包/拆包发生的原因解决方法
一个完整的业务可能会被TCP拆分成多个包进行发送也有可能把多个小的包封装成一个大的数据包发送这个就是TCP的拆包和粘包问题。
原因 1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.
2、进行MSS大小的TCP分段。( MSSTCP报文段长度-TCP首部长度)
3、以太网的payload大于MTU进行IP分片。 MTU指一种通信协议的某一层上面所能通过的最大数据包大小。
解决方案 1、增加消息长度字段。
2、在包尾部增加回车或者空格符等特殊字符进行分割
3、将消息分为消息头和消息尾
4、使用其它复杂的协议如RTMP协议等。
TCP和UDP的区别
连接TCP是面向连接的传输层协议传输数据前需要先建立连接而UDP是不需要连接即刻传输数据。服务对象TCP是一对一两点服务UDP支持一对一、一对多和多对多可靠性TCP是可靠交付数据数据可以无差错、不丢失、不重复、按需到达UDP是尽最大努力交付不保证可靠交付数据拥塞控制、流量控制TCP有拥塞控制和流量控制机制保证数据传输的安全性UDP则没有即便是网络非常拥堵也不会影响UDP的发送速率。首部开销TCP首部长而UDP首部只有8个字节传输方式TCP是流式传输没有边界但是保证顺序和可靠UDP是一个包一个包的发送是有边界的但是可能会丢包和乱序。
TCP和UDP的应用场景
由于TCP是面向连接的能够保证数据的可靠性交付因此经常被用于FTP文件传输HTTP、HTTPS
由于UDP是面向无连接的它可以随时发送数据加上UDP本身的处理既简单又高效因此经常用于包总量较少的通信如DNS、SNMP等视频音频等多媒体通信广播通信。
为什么TCP有「首部⻓度」字段UDP没有
原因是 TCP 有可变⻓的「选项」字段⽽ UDP 头部⻓度则是不会变化的⽆需多⼀个字段去记录 UDP 的⾸部⻓度。
TCP报文结构 端口号TCP是进程与进程间的通信因此头部两端是16位的源端口号和16位的目的端口号 序列号SEQ在建立连接时由计算机生成的随机数作为其初始值通过SYN包传递给接收端主机每发送一次数据就累加一次该数据字节数的大小用来解决网络包乱序问题。 确认应答号ACK指下一次期望收到数据的序列号发送端收到这个应答以后可以认为在这个序号以前的数据都已经被正常接收用来解决不丢包的问题。 控制位ACK该位为 1 时「确认应答」的字段变为有效TCP 规定除了最初建⽴连接时的 SYN 包之外该位必须设置为 1。 RST该位为 1 时表示 TCP 连接中出现异常必须强制断开连接。 SYN该位为 1 时表示希望建⽴连接并在其「序列号」的字段进⾏序列号初始值的设定。 FIN该位为 1 时表示今后不会再有数据发送希望断开连接。当通信结束希望断开连接时通信双⽅的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。 窗口大小用于拥塞控制 校验和差错控制 紧急指针仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数占 16 位。当所有紧急数据处理完后TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0也是可以发送紧急数据的因为紧急数据无须缓存。 选项Option长度不定但长度必须是 32bits 的整数倍。 数据
TCP建立连接为什么是3次握手而不是2次或者4次
三次握手才可以阻止重复历史连接的初始化首要原因三次握手才可以同步双方的初始序列号三次我说才可以避免资源浪费
客户端连续发送多次SYN建立连接的报文在网络拥堵情况下一次旧的SYN报文比新的SYN报文到达了服务端那么此时服务端就会返回一个SYN ACK报文给客户端客户端收到后可以根据自身的上下文判断这是一个历史连接序列化过期或者超时那么客户端就会发送RST报文给服务端表示终止这一次连接。
如果是两次握手就不足以判断当前连接是否为历史连接。
SYN攻击DDOS攻击原理及避免方法
我们都知道 TCP 连接建⽴是需要三次握⼿假设攻击者短时间伪造不同 IP 地址的 SYN 报⽂服务端每接收到⼀个 SYN 报⽂就进⼊ SYN_RCVD 状态但服务端发送出去的 ACK SYN 报⽂⽆法得到未知 IP 主机的 ACK 应答久⽽久之就会占满服务端的 SYN 接收队列未连接队列使得服务器不能为正常⽤户服务。 TCP连接4挥手断开连接 客户端打算关闭连接此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报⽂也即 FIN 报⽂之后客户端进⼊ FIN_WAIT_1 状态。服务端收到该报⽂后就向客户端发送 ACK 应答报⽂接着服务端进⼊ CLOSED_WAIT 状态。客户端收到服务端的 ACK 应答报⽂后之后进⼊FIN_WAIT_2 状态。等待服务端处理完数据后也向客户端发送 FIN 报⽂之后服务端进⼊ LAST_ACK 状态。客户端收到服务端的 FIN 报⽂后回⼀个 ACK 应答报⽂之后进⼊ TIME_WAIT 状态服务器收到了 ACK 应答报⽂后就进⼊了 CLOSED 状态⾄此服务端已经完成连接的关闭。客户端在经过 2MSL ⼀段时间后⾃动进⼊ CLOSED 状态⾄此客户端也完成连接的关闭。
MSL 是 Maximum Segment Lifetime报⽂最⼤⽣存时间
TCP重传机制
TCP 针对数据包丢失的情况会⽤重传机制解决。常见的重传机制如下
超时重传是在发送数据时设定⼀个定时器当超过指定的时间后没有收到对⽅的 ACK 确认应答报⽂就会重发该数据也就是我们常说的超时重传。发送数据包丢失和对方ACK数据包丢失都会触发超时重传
RTORetransmission Timeout 超时重传时间根据RTTRound-Trip Time 往返时延/确定。 快速重传 快速重传的⼯作⽅式是当收到三个相同的 ACK 报⽂时会在定时器过期之前重传丢失的报⽂段。 快速重传机制只解决了⼀个问题就是超时时间的问题但是它依然⾯临着另外⼀个问题。就是重传的时候是重 传之前的⼀个还是重传所有的问题。 ⽐如对于上⾯的例⼦是重传 Seq2 呢还是重传 Seq2、Seq3、Seq4、Seq5 呢因为发送端并不清楚这连续的 三个 Ack 2 是谁传回来的。 SACK Selective Acknowledgment 选择性确认重传 这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄它可以将缓存的地图发送给发送⽅这样发送⽅就可以知道哪些数据收到了哪些数据没收到知道了这些信息就可以只重传丢失的数据。 如下图发送⽅收到了三次同样的 ACK 确认报⽂于是就会触发快速重发机制通过 SACK 信息发现只有200~299 这段数据丢失则重发时就只选择了这个 TCP 段进⾏重复。如果要⽀持 SACK 必须双⽅都要⽀持。在 Linux 下可以通过 net.ipv4.tcp_sack 参数打开这个功能Linux2.4 后默认打开。 4. Duplicate SACK ⼜称 D-SACK 其主要使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。 例子1
「接收⽅」发给「发送⽅」的两个 ACK 确认应答都丢失了所以发送⽅超时后᯿传第⼀个数据包3000 ~ 3499于是「接收⽅」发现数据是重复收到的于是回了⼀个 SACK 3000~3500告诉「发送⽅」 3000~3500 的数据早已被接收了因为 ACK 都到了 4000 了已经意味着 4000 之前的所有数据都已收到所以这个 SACK就代表着 D-SACK 。这样「发送⽅」就知道了数据没有丢是「接收⽅」的 ACK 确认报⽂丢了。
例子2
数据包1000~1499 被⽹络延迟了导致「发送⽅」没有收到 Ack 1500 的确认报⽂。⽽后⾯报⽂到达的三个相同的 ACK 确认报⽂就触发了快速重传机制但是在重传后被延迟的数据包1000~1499⼜到了「接收⽅」所以「接收⽅」回了⼀个 SACK1000~1500因为 ACK 已经到了 3000所以这个 SACK 是 D-SACK表示收到了重复的包。这样发送⽅就知道快速重传触发的原因不是发出去的包丢了也不是因为回应的 ACK 包丢了⽽是因为⽹络延迟了。
可见使用D-SACK的好处是
可以让发送方知道是发出的包丢了还是接收方回应的ACK包丢了可以知道是不是发送包的数据包被网络延迟了
在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能Linux 2.4 后默认打开。
TCP滑动窗口
#1 是已发送并收到 ACK确认的数据1~31 字节 #2 是已发送但未收到 ACK确认的数据32~45 字节 #3 是未发送但总⼤⼩在接收⽅处理范围内接收⽅还有空间46~51字节 #4 是未发送但总⼤⼩超过接收⽅处理范围接收⽅没有空间52字节以后 TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针指特 定的序列号⼀个是相对指针需要做偏移。 接收部分如上图所示其中三个接收部分使⽤两个指针进⾏划分: RCV.WND 表示接收窗⼝的⼤⼩它会通告给发送⽅。 RCV.NXT 是⼀个指针它指向期望从发送⽅发送来的下⼀个数据字节的序列号也就是 #3 的第⼀个字节。 指向 #4 的第⼀个字节是个相对指针它需要 RCV.NXT 指针加上 RCV.WND ⼤⼩的偏移ᰁ就可以指向 #4 的 第⼀个字节了。
流量控制
发送⽅不能⽆脑的发数据给接收⽅要考虑接收⽅处理能⼒。 如果⼀直⽆脑的发数据给对⽅但对⽅处理不过来那么就会导致触发重传机制从⽽导致⽹络流重的⽆端的浪费。
为了解决这种现象发⽣TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量 这就是所谓的流量控制。
1、假如发送方报文丢失那么接收方回传的ack会一直不包含丢失字段则发送方会在重传等待时间结束后对丢失报文段进行重传。接收方利用接受窗口大小这个参考控制发送方的发送速率。
2、假如接收方有了新的可缓存空间并将消息发送给发送方的途中报文丢失那么发送方一直以为接收方没有空间接收而接收方也并不知道自己的报文丢失。这样就陷入死锁状态。为了打破死锁发送方每发送一次报文都会启动一个持续计时器当持续计时器超时的时候发送零窗口探测报文。询问是否依旧是没有缓存空间。零窗口探测报文对于接收方没有空间要求且也有超时重传机制。
拥塞控制
前⾯的流量控制是避免「发送⽅」的数据填满「接收⽅」的缓存但是并不知道⽹络的中发⽣了什么。
而拥塞控制是当⽹络发送拥塞时TCP 会⾃我牺牲降低 发送的数据量。控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。
拥塞控制主要是4个算法 慢开始从1开始倍数增长。 拥塞避免如果当拥塞窗⼝ cwnd 「超过」慢启动⻔限 ssthresh就进入拥塞避免算法。一般ssthresh的大小是65535。进入拥塞避免算法后每次线性增加1。如果网络发送拥塞有丢包现象发生就会触发重传机制将ssthresh 设为 cwnd/2cwnd窗口值设置为1并执行慢开始算法。 快重传发送方一旦收到3个连续的重复确认立即重传相应报文段。TCP认为在还能收到3个连续重复确认的情况下说明大部分没丢只是丢了一小部分。于是将cwnd拥塞窗口设置为原来的一半将ssthresh设置为cwnd然后进入快速恢复算法。 快恢复拥塞窗口 cwnd ssthresh 33的意思是确认有3个数据包收到了重传丢失的数据包如果再收到重复的ACK那么cwnd增加1.
UDP协议
应用层
HTTP
HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和 规范」
HTTP状态码 1xx 类状态码属于提示信息是协议处理中的⼀种中间状态实际⽤到的⽐较少
2xx 类状态码表示服务器成功处理了客户端的请求也是我们最愿意看到的状态
「200 OK」是最常⻅的成功状态码表示⼀切正常。如果是⾮ HEAD 请求服务器返回的响应头都会有 body数据「204 No Content」也是常⻅的成功状态码与 200 OK 基本相同但响应头没有 body 数据。「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传表示响应返回的 body 数据并不是资源的全部⽽是其中的⼀部分也是服务器处理成功的状态
3xx 类状态码表示客户端请求的资源发送了变动需要客户端⽤新的 URL新发送请求获取资源也就是重定向。
「301 Moved Permanently」表示永久重定向说明请求的资源已经不存在了需改⽤新的 URL 再次访问。「302 Found」表示临时重定向说明请求的资源还在但暂时需要⽤另⼀个 URL 来访问。301 和 302 都会在响应头⾥使⽤字段 Location 指明后续要跳转的 URL浏览器会⾃动重定向新的 URL。「304 Not Modified」不具有跳转的含义表示资源未修改᯿定向已存在的缓冲⽂件也称缓存重定向⽤于缓存控制
4xx 类状态码表示客户端发送的报⽂有误服务器⽆法处理也就是错误码的含义。
「400 Bad Request」表示客户端请求的报⽂有错误但只是个笼统的错误。「403 Forbidden」表示服务器禁⽌访问资源并不是客户端的请求出错。「404 Not Found」表示请求的资源在服务器上不存在或未找到所以⽆法提供给客户端。
5xx 类状态码表示客户端请求报⽂正确但是服务器处理时内部发⽣了错误属于服务器端的错误码。
「500 Internal Server Error」与 400 类型是个笼统通⽤的错误码服务器发⽣了什么错误我们并不知道。「501 Not Implemented」表示客户端请求的功能还不⽀持类似“即将开业敬请期待”的意思。「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码表示服务器⾃身⼯作正常访问后端服务器发⽣了错误。「503 Service Unavailable」表示服务器当前很忙暂时⽆法响应服务器类似“⽹络服务正忙请稍后重试”的意思。
GET和POST的区别
Get 获取⽅法的含义是请求从服务器获取资源这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。
POST投递 ⽅法则是相反操作它向 URI 指定的资源提交数据数据就放在报⽂的 body ⾥。
HTTP和HTTPS的区别
HTTP是超文本传输协议信息是明文传输存在安全风险问题HTTPS则解决了HTTP不安全的缺陷在TCP和HTTP网络层之间加入了SSL/TLS安全协议使得报文能够加密传输。HTTP连接建立简单TCP三次握手之后便可以进行HTTP的报文传输而HTTPS在TCP三次握手之后还需要进行SSL/TSL握手才可以进入加密报文传输。HTTP的端口号是80HTTPS的端口号是443HTTPS协议需要向CA(证书权威机构)申请数字证书来保证服务器身份是可信的。
HTTPS解决了HTTP哪些问题是怎么解决的
HTTP由于是明文传输安全上存在窃听、篡改和冒充的风险。 HTTPS在HTTP与TCP层之间加入了SSL/TSL协议通过对信息的混合加密防止窃听采用校验机制使用摘要算法为数据生成独一无二的指纹用于校验数据的完整性防止数据篡改将服务器公钥放入到数字证书中解决身份冒充的风险。
SLL/TLS协议基本流程
客户端向服务器索要并验证服务器的公钥双方协商生成会话秘钥双方采用会话秘钥进行加密通信
前两步也就是SSL/TSL的建立过程也就是握手阶段。
HTTP/1.1、HTTP/2、HTTP/3演变
域名解析协议DNSDomain Name System
客户端⾸先会发出⼀个 DNS 请求问 www.server.com 的 IP 是啥并发给本地 DNS 服务器也就是客户端 的 TCP/IP 设置中填写的 DNS 服务器地址。本地域名服务器收到客户端的请求后如果缓存⾥的表格能找到 www.server.com则它直接返回 IP 地址。如 果没有本地 DNS 会去问它的根域名服务器“⽼⼤ 能告诉我 www.server.com 的 IP 地址吗” 根域名服 务器是最⾼层次的它不直接⽤于域名解析但能指明⼀条道路。根 DNS 收到来⾃本地 DNS 的请求后发现后置是 .com说“www.server.com 这个域名归 .com 区域管 理”我给你 .com 顶级域名服务器地址给你你去问问它吧。”本地 DNS 收到顶级域名服务器的地址后发起请求问“⽼⼆ 你能告诉我 www.server.com 的 IP 地址吗”顶级域名服务器说“我给你负责 www.server.com 区域的权威 DNS 服务器的地址你去问它应该能问到”。本地 DNS 于是转向问权威 DNS 服务器“⽼三www.server.com对应的IP是啥呀” server.com 的权威 DNS 服务器它是域名解析结果的原出处。为啥叫权威呢就是我的域名我做主。权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。本地 DNS 再将 IP 地址返回客户端客户端和⽬标建⽴连接。 为什么域名解析用UDP协议
因为UDP快啊UDP的DNS协议只要一个请求、一个应答就好了。 而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手但是UDP协议传输内容不能超过512字节。 不过客户端向DNS服务器查询域名一般返回的内容都不超过512字节用UDP传输即可。
动态主机配置协议DHCPDynamic Host Configuration Protocol Linux网络编程
TCP的socket编程 服务端和客户端初始化 socket 得到⽂件描述符服务端调⽤ bind 将绑定在 IP 地址和端⼝;服务端调⽤ listen 进⾏监听服务端调⽤ accept 等待客户端连接客户端调⽤ connect 向服务器端的地址和端⼝发起连接请求服务端 accept 返回⽤于传输的 socket 的⽂件描述符客户端调⽤ write 写⼊数据服务端调⽤ read 读取数据客户端断开连接时会调⽤ close 那么服务端 read 读取数据的时候就会读取到了 EOF 待处理完数据后服务端调⽤ close 表示连接关闭。
需要注意的是监听的 socket 和真正⽤来传送数据的 socket是「两个」 socket⼀个叫作监听 socket⼀个叫作已完 成连接 socket。
成功连接建⽴之后双⽅开始通过 read 和 write 函数来读写数据就像往⼀个⽂件流⾥⾯写东⻄⼀样。
Linux内核中会维护两个队列
半连接队列SYN 队列接收到⼀个 SYN 建⽴连接请求处于 SYN_RCVD 状态全连接队列Accpet 队列已完成 TCP 三次握⼿过程处于 ESTABLISHED 状态
