计算机网络通信 入门基础(核心笔记)

iso7层模型

网络连接 结构为
客户端主机–(客户端)路由器–网络–(服务器端)路由器–服务器主机
在这里插入图片描述
如何理解 的概念,其实就是7个步骤

分层就是为了标准化和降低每一层之间的相互影响和关联。

客户端(Client)或称为用户端,是指与服务器相对应,为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外,一般安装在普通的客户机上,需要与服务端互相配合运行。因特网发展以后,较常用的用户端包括了如万维网使用的网页浏览器,收寄电子邮件时的电子邮件客户端,以及即时通讯的客户端软件等。对于这一类应用程序,需要网络中有相应的服务器和服务程序来提供相应的服务,如数据库服务,电子邮件服务等等
其实简单来说,客户端就是你手机或者电脑上安装的各种应用程序,客户端往往要比网页端功能更加全面,而且网页端有各种不方便的限制,而客户端就不会出现这个问题。

1应用层:能够产生 网络流量 能够和用户交互的 应用程序
2表示层: 在传输之前是否要 进行 数据加密,压缩 处理
3会话层:服务客户端(客户端,客户端某个应用程序)建立的会话。应用程序之间建立的会话 可用来查木马

会话可以理解为:一种特定搭配的连接关系。这种连接双方共同遵守特定的协议。 一种包含 特定关系双方 之间的 特定关系 。
比如这里tcp协议中的 客户端和服务器端建立的会话 可以包括这些信息:发了多少个数据包了,好有几个数据包没发,某个数据包丢了之后让服务器再重传。 客户端与服务端一定要 维持这种关系,直到数据传输完成,这个会话就结束了。

4传输层:可靠传输(建立会话)(比如看电影),不可靠传输(不建立会话)(比如qq,网页网址请求),流量控制

运输层 :提供的是进程间的通用数据传输服务。是为主机中的进程提供服务。由于应用层协议很多,定义通用的运输层协议就可以支持不断增多的应用层协议。运输层包括两种协议:
传输控制协议TCP,提供面向连接、可靠的数据传输服务,数据单位为报文段;TCP 主要提供完整性服务.
用户数据报协议UDP,提供无连接、尽最大努力的数据传输服务,数据单位为用户数据报。UDP 主要提供及时性服务。

5网络层:选择最佳路径,规划ip地址。

网络层:为主机间提供数据传输服务,而运输层协议是为主机中的进程提供服务。网络层把运输层传递下来的报文段或者用户数据报封装成分组

6数据链路层:数据如何封装,(要传输的)帧 的开始和结束,
添加物理层地址,
添加MAC地址,
透明传输(传出去的数据和收到的数据要相同),
差错校验(检验 传出的数据和收到的数据 是否有 差错,变化 发生),
但是发生错误了数据链路层不纠错,纠错 由传输层来进行。

数据链路层:网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路,链路层协议就是为同一链路的节点提供服务。数据链路层把网络层传来的分组封装成帧。

7物理层:电器标准电压,接口标准,如何在物理链路上传输更快

物理层 :考虑的是怎样在传输媒体上传输数据比特流,而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使数据链路层感觉不到这些差异。

传输层
TCP与UDP的特点
用户数据报协议 UDP(User Datagram Protocol):无连接的,尽最大可能交付,没有拥塞控制,面向报文

对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部,支持一对一、一对多、多对一和多对多的交互通信。

传输控制协议 TCP(Transmission Control Protocol)是有连接的,提供可靠交付,有流量控制,拥塞控制,面向字节流

把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块,每一条 TCP连接只能是点对点的(一对一)。

总结(TCP和UDP的区别):
1)TCP提供面向连接的传输;UDP提供无连接的传输

2)TCP提供可靠的传输(有序,无差错,不丢失,不重复);UDP提供不可靠的传输。

3)TCP面向字节流的传输,因此它能将信息分割成组,并在接收端将其重组;UDP是面向数据报的传输,没有分组开销。

4)TCP提供拥塞控制和流量控制机制;UDP不提供拥塞控制和流量控制机制。

5)TCP只能是点对点的(一对一)。UDP支持一对一、一对多、多对一和多对多的交互通信。
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述网络接口层:数据链路层+物理层

在这里插入图片描述在这里插入图片描述
应用层的 数据单位 为报文
在这里插入图片描述
FCS是校验核,负责数据帧的差错校验
bit 比特流

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
这幅图的意思:
我的客户端应用程序 向 服务器 发请求,
服务器把数据给我。
这个过程,通过网络的这一个个的封装,再通过网线传输。
对于我这个应用程序 来说,这是透明的。
也就是说,我的应用程序不知道中间走了多少个路由器,选择的什么路径,不知道这个事情。

客户端与服务器之间只要网络通,他就能进行这个过程,(我的客户端应用程序 向 服务器 发请求,服务器把数据给我。),跟别的因素没有关系。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
SYN:同步标记位,同步标记号(同步数据包)
ACK:确认标记位,确认标记号。
seq:序号 (等于上一个反方向的ack,或者等于 上上 一个同方向的seq+1)
ack:确认号(用来回复上一个反方向的seq,值为seq+1)

在这里插入图片描述
服务器的状态:
在这里插入图片描述
在这里插入图片描述

为什么是三次而不是两次:

就是考虑 客户端第一个请求建立连接的数据包走远的路径,存在延迟,然后客户端重新发送一个请求建立连接的快速数据包,然后直接与服务器建立连接。而这个延迟的数据包 会在不定的时候到达 服务器。引起服务器端回复,但是客户端因为已经回复了第二次发送的快速数据包而不再回复延迟的这个数据包,认为是重复包(第一次发送的延迟数据包和第二次发送的快速数据包携带完全相同的数据,因此客户端对携带完全相同信息的数据包只会回复一次)。或者客户端已经关闭而不回复。 造成 服务器的资源浪费,时间多了就会导致服务器瘫痪或者奔溃。

如果两次,客户端第一个请求建立连接的信号如果经过一个很长的网络,然后没有收到回复,这时候客户端你再发送一个请求建立的链接,这时候服务端收到后,回复,然后直接开启会话。
后面那个走的很长的第一个请求建立连接的信号 到达了服务器端,这时候服务端回复,但是客户端已经关闭,导致服务器端的请求没人回复处理。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
FIN:希望断开连接标记位
ACK:确认标记位,确认标记号。
seq:序号 (等于上一个反方向的ack,或者等于 上上 一个同方向的seq+1)
ack:确认号(用来回复上一个反方向的seq,值为seq+1)

在这里插入图片描述
在这里插入图片描述

序号seq :用于对字节流进行编号,例如序号为 301,表示第一个字节的编号为 301,如果携带的数据长度为 100 字节,那么下一个报文段的序号应为 401。
确认号ack :期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段,序号为 501,携带的数据长度为 200 字节,因此 B 期望下一个报文段的序号为 701,B 发送给 A 的确认报文段中确认号就为 701。
数据偏移 :指的是数据部分距离报文段起始处的偏移量,实际上指的是首部的长度。
确认 ACK :当 ACK=1 时确认号字段有效,否则无效。TCP 规定,在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN :在连接建立时用来同步序号。当 SYN=1,ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接,则响应报文中 SYN=1,ACK=1。
终止 FIN :用来释放一个连接,当 FIN=1 时,表示此报文段的发送方的数据已发送完毕,并要求释放连接。
窗口 :窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
有可能客户端的最后一个ACK丢失。

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可能客户端的最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。**所以Client不能立即关闭,**它必须确认Server接收到了该ACK。****Client会在发送出ACK之后进入到TIME_WAIT状态。
Client会设置一个计时器,等待2MSL的时间。
如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。

所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。
MSL指一个片段在网络中最大的存活时间,
2MSL就是一个发送和一个回复所需的最大时间。
如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

在这里插入图片描述

【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端**,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。**故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

【问题3】为什么不能用两次握手进行连接?

答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。

   现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?

TCP还设有一个保活计时器,
显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。
服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,
若两小时还没有收到客户端的任何数据,服务器就会发送一个 探测报文段,以后每隔75秒钟发送一次。
若一连发送10个探测报文仍然没反应,
服务器就认为客户端出了故障,
接着就关闭连接。

TCP采用四次挥手关闭连接如图所示为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。

而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值