<>TCP/IP

<>1. TCP/IP 是互联网的核心协议
- 从上而下,四个层次,分别是应用层,传输层,网络层,链路层 - 应用层:HTTP,FTP 等协议 - 传输层:TCP、UDP 协议 - 网络层:IP 协议
- 链路层:给数据增加以太网协议头,并进行CRC编码校验
<>2. 数据链路层
(1) 物理层负责0、1 比特流与物理设备电压高低、光的闪灭之间的互换。
(2)数据链路层负责将0、1序列划分为数据帧从一个节点传输到临近的另一个节点,这些节点是通过MAC来唯一标识的(MAC,物理地址,一个主机有唯一的MAC地址)
- 封装成帧: 把网络层数据报加头和尾,封装成帧,帧头中包括源MAC地址和目的MAC地址。 - 透明传输:零比特填充,转义字符。 -
可靠传输:在出错率很低的链路上很少用,但是无线链路WLAN会保证可靠传输。 - 出错检测(CRC):接收者检测错误,如果发现差错,丢弃该帧。
<>3. 网络层

(1)IP协议

IP协议是TCP/IP协议的核心,所有的TCP,UDP,IMCP,IGMP的数据都以IP数据格式传输。要注意的是,IP不是可靠的协议,这就是说,IP协议没有提供一种数据未传达以后的处理机制,这被认为是上层协议:TCP或UDP要做的事情
**1.1 IP地址** - 在数据链路层中,我们一般通过MAC地址来识别不同的节点,在IP层,我们通过IP地址来识别地址标识。 -
32位IP地址,分为网络位和地址位,这样做可以减少路由器中路由表记录的数目,有了网络地址,就可以限定拥有相同网络地址的终端都在同一个范围内,那么路由表只需要维护一条这个网络地址的方向,就可以找到相应的这些终端了。
``` A类IP地址:0.0.0.0 ~ 127.0.0.0 A类IP地址:128.0.0.1 ~ 191.255.0.0
A类IP地址:192.168.0.0 ~ 239.255.255.0 ``` **1.2 IP 协议头**(TTL) -
这里只介绍:八位的TTL字段。这个字段规定数据包在穿过多少个路由之后才会被抛弃。某个IP数据包每穿过一个路由器,该数据包的TTL数值就会减少1,当该数据包的TTL成为0,它就会自动被抛弃。
- 这个字段的最大值是255,也就是谁,一个协议包也就是在路由器里穿行255次就会被抛弃了。
(2)ARP及RARP协议

* ARP是根据IP地址获取MAC地址的一种协议
*
ARP(地址解析)协议是一种解析协议,本来主机是完全不知道这个IP对应的是哪个主机的MAC接口,当主机要发送一个IP包的时候,会先查一下自己的ARP缓存。
*
如果查询不到,主机就向网络发送一个ARP协议广播包,这个广播包里面就有待查询的IP地址,而直接受到这份广播包的所有主机都会查询自己的IP地址,如果发现自己符合,就准备好一个包含自己的MAC地址的ARP包传送给ARP广播的主机。
* 广播的主机拿到ARP包后会更新的ARP缓存(IP-MAC对应表)。然后发送广播的主机就会用心的ARP缓存数据准备好链路层的数据包发送工作。
* RARP 协议的工作与此相反,不做赘述
(3)ICMP 协议

* IP
协议并不是一个可靠的协议,它不保证数据被送达,那么,自然的,保证数据送达的工作应该由其他的模块来完成。其中一个重要的模块就是ICMP(网络控制报文)协议。ICMP不是高层协议,而是IP层的协议。
* 当传送IP数据包发送错误,比如主机不可达,路由不可达等,ICMP协议将会把错误信息封包,然后传送回主机,给主机一个处理错误的机会。
<>4. ping
- ping可以说是ICMP的最著名的应用,是TCP/IP协议的一部分。利用"ping"命令可以检查网络是否连通,可以很好第帮助我们分析和判断网络故障。 -
它利用ICMP协议包来侦测另一个主机是否可达。 - 用类型码为0的ICMP发请求,受到请求的主机则用类型码为8的ICMP回应。 -
ping程序来计算间隔时间,并计算有多少个包被送达。用户就可以判断网络大致的情况。我们可以看到,ping给出来了传送的时间和TTL的数据。
<>5. TraceRoute
- TraceRoute是用来侦测主机到目的主机之间所经路由情况的重要工具,也是最便利的工具。 - TraceRoute的原理是非常有意思。 -
它收到目的主机的IP后,首先给目的主机发送一个TTL=1的UDP数据,而经过的第一个路由器收到这个数据包后,就自动把TTL减1,变为0了,这个时候路由器就把这个包丢弃了,并同时产生一个主句不可达的ICMP数据报回给主机。
- 主机收到收到这个数据包以后,再发一个TTL=2的UDP数据报给目的主机,刺激第二个路由器给主机发ICMP数据报。 -
如此循环,TraceRoute就可以拿到所有路由器的IP。
<>6. TCP/UDP

TCP/UDP都是传输层协议,但是两者具有不同的特性,同时也具有不同的应用场景。

(1)面向报文

面向报文的传输方式是应用层 交给 UDP 多长的报文,UDP 就照样发送,即一次发送一个报文。因此,应用程序必须选择大小合适的报文。
如果报文太长了,则IP层需要额外的分片工作,就会降低了效率。

(2)面向字节流

* 面向字节流的话,虽然应用程序 和 TCP
的交互是一次一个数据块(大小不等),但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些在传送。
(3)拥塞控制
1.`慢开始`和`拥塞避免`
* 发送方维持一个拥塞窗口的状态变量,拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送发让自己的发送窗口等于拥塞窗口
*
发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。但只要网络出现拥塞,拥塞窗口减小一些,以减少注入到网络中的分组数。
* (a)慢开始算法
(1) 当主机开始发送数据时,如果立即将大量的数据注入到网络中,那么就有可能引起网络拥塞,因为现在并不清楚网络的负荷情况。
(2) 所以,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是说,有小到大逐渐增加拥塞窗口数值。
(3)
通常,在刚刚开始发送报文时,先把拥塞窗口cwnd设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd,可以使分组注入到网络的速率更合理。
(4) 每经过一个传输轮次,拥塞窗口cwnd就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过传输轮次
更加强调:把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。
(5) 慢开始的慢
并不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时,先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd。
(6) 为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下:
当 cwnd < ssthresh 时,使用上述的慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法
当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞控制避免算法。
拥塞避免
让拥塞窗口cwnd缓慢地线性增大,而不是加倍。
(7)
无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。

* 快重传和快恢复
快重传
(1)
快重传算法首先要求接收方每收到一个失序的报文段后,就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时才进行捎带确认。
(2) 接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。
(3) 显然,接收方不能确认M4,因为M4是失序的报文段。根据可靠传输原理,接收方可以什么都不做,也可以在适当时机发送一次对M2的确认。
(4) 但按照快重传算法的规定,接收方应及时发送对M2的重复确认,这样做可以让发送方及早知道报文M3没有到达接收方。发送方接着发送了M5
和M6。接收方收到这两个报文后,也还要再次发出对M2的重复确认。这样,发送方共收到了接收方的四个对M2的确认,其中后三个都是重复确认。
快重传算法还规定,发送方只要一连接收到三个重复确认就应当立即重传对方尚未收到的报文段M3,而不必继续等待M3设置的重传计时器到期。
(4) 由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%

快恢复

(1) 当发送方连续收到3个重复确认,就执行“乘法减小”算法,把慢开始门限ssthresh减半
(2)
与慢开始不同之处是,现在不执行慢开始算法(即拥塞窗口cwnd现在不设置为1),而是把cwnd值设置为门限ssthresh减半后的数值,然后开始执行拥塞算法(线性增大)

(4)流量控制

* 如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的速率不要太快,要让接收方来得及接收。
* 利用滑动窗口机制就可以很方便地在TCP连接上实现对发送方的流量控制。
* 假设:A向B发送数据,在连接建立时,B告诉A: “我的接收窗口是rwnd=400字节”。因此,发送方的窗口不能大于接收方的窗口的数值。
(5)三次握手

* 第一次握手:建立连接,客户端发送连接请求报文段,将SYN位置置为1,Sequence Number为X;
此刻客户端进入SYN_SEND状态,等待服务器的确认;
* 第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledge
Number为(x+1); 同时,将SYN设置为1,Sequence
Number为服务器将上述所有信息放到一个报文段中,一并发送给客户端,此时服务器进入SYN_RECV状态;
* 第三次握手:客户端收到服务器的SYN+ACK报文段后,然后将Acknowledge
Number为(y+1);向服务器发送ACK报文段,客户端和服务端都进入establish状态。完成三次握手。
为什么采用三次握手?

* 当上一次的连接请求,由于网络节点延时问题,过了很久才到达客户端。其实这个是一个失效的连接请求。
* 但是客户端收到这个连接请求后,如果两次握手就成功了,那么其实这个时候客户端是白白地建立了连接,实际上并没有客户端真正的想建立连接。
* 如果三次握手,客户端就会进行确认,实际上,这个时候,客户端并不会确认,这样就可以保证正确的建立连接。
(6) 四次挥手

* 第一次挥手:主机1(可以是客户端,也可以是服务端),设置Sequence
Number,向主机2发送一个FIN(finish)报文段;此时主机1进入FIN_WAIT状态,此时主机1没有了数据要向主机2发送了。
* 第二次挥手:主机2接收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,acknowledge Number为 Seq + 1,
主机2告诉主机1:“我同意你的关闭请求”
* 第三次挥手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;
*
第四次挥手:主机1收到主机2的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明主机2已经正常关闭,主机1也可以正常关闭连接了。
为什么要四次挥手

* 因为TCP传输数据是全双工的,所以,当主机1要关闭连接的时候,主机2可能还有数据准备发送。
* 第一次:所以,主机1先通知主机2要断开连接,
-第二次:主机2接收到断开请求后,先发送同意请求断开,但是要先确保自己也没有了数据准备发送,
* 第三次:然后再发送断开请求。主机2向主机1发送请求。
* 第四次:主机1就断开了请求。
为什么要等到2MSL

* MSL:报文段在互联网传输中最大生存时间
* 原因一:保证TCP协议的全双工连接能够可靠关闭
* 如果主机1直接关闭了,可能因为网络的问题,主机2没有收到主机1的最后ACK报文,主机2就会重复发送FIN。2倍的MSL刚好够消息发送的一个来回时间。
* 原因二:保证这次连接的重复数据段从网络中消失
*
如果上一次断开后,马上又建立请求了,又恰好是同一个端口,那么上一次连接请求中的数据,还没彻底在互联网上消失,又被当成了这一次的新的数据请求报文。就会发送数据错乱。
*
如果已经建立了连接,但是Client端突然出现故障了怎么办?

TCP还设有一个保活计时器,Client端如果出现故障,Server端不能一直等下去,这样会浪费系统资源。每收到一次Client客户端的数据帧后,Server端都的保活计时器会复位。
计时器的超时时间通常是设置为2小时,若2小时还没有收到Client端的任何数据帧,Server端就会发送一个探测报文段
,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,Server端就认为Client端出了故障,接着就关闭连接。如果觉得保活计时器的两个多小时的间隔太长,可以自行调整TCP连接的保活参数。

<>7. DNS

* 一般是用来做域名解析的,把域名和IP地址做一个映射存储的一个分布式数据库。用户就不用记忆ip地址,而是方便地记忆域名了。

技术
下载桌面版
GitHub
Gitee
SourceForge
百度网盘(提取码:draw)
云服务器优惠
华为云优惠券
腾讯云优惠券
阿里云优惠券
Vultr优惠券
站点信息
问题反馈
邮箱:[email protected]
吐槽一下
QQ群:766591547
关注微信