-
传输单位:报文段或分组
-
功能:提供应用进程间的逻辑通信;差错检测;提供有连接和无连接的服务;复用和分用;流量控制(GBN,SR);可靠传输;
-
协议:TCP、UDP
-
问:套接字?
-
答:数据链路层按 MAC 地址寻址,网络层按 IP 寻址,而传输层按端口号寻址。套接字是 (IP + 端口),TCP连接的端口,不是IP,不是主机,是套接字。
-
问:传输层提供应用进程间的逻辑通信?
-
答:是的,传输层以端口寻址,应用进程与外界通信也是通过端口号。
-
问:差错检测?
-
答:TCP 是面向字节的,TCP 将所要传送的报文看成是字节组成的数据流,并使每一个字节对应于一个序号。对收到的报文进行首部和数据进行差错检测,网络层不检查数据部分。
-
问:传输层如何提供有连接和无连接的服务?
-
答:一个 TCP,一个 UDP 嘛。
-
问:复用和分用?
-
答:这里的概念是不同的应用进程可以使用一个传输层协议,分用就是逆过程,将不同的数据取出后分给目标应用。其实看的更多的是数据链路层的复用,为了提高电缆的传输效率,可以同时将多个不同频率信号通过一条电缆传输,有时分-频分-码分-波分多路复用。时分多路复用:现在有一个玩具,十个小孩想玩,那么只能将能玩的时间分成十份,然后轮流玩。如果中间轮到有的孩子他睡着了怎么办,跳过它,到下一个,这就是 异步时分多路复用(ATM),如果要干等着,那就是同步了。
-
问:在传输层应根据什么原则来确定使用面向连接服务还是无连接服务?
-
答:当然是根据上层老板的要求了,一个提供服务的有啥话语权,叫你用啥就用啥。比如要使用 FTP 文件传送协议时,赶紧准备好 TCP,当应用程序要视频点播,实时传送时,用 UDP 伺候着。
-
特点:是面向字节流的传输协议,传送数据前需要建立连接,可靠交付,但是时延长,要求实时性肯定不行了,但是要求可靠,那杠杠的。如文件传输协议 FTP,需要使用 TCP连接。
-
要点:可靠传输、流量控制、拥塞控制、三次握手,四次挥手。
-
问:传输层如何实现可靠传输?
-
答:传输层的可靠性是由 TCP 实现的,所以我们可以叫 TCP 可靠传输。TCP 的可靠性表现在:它向应用层提供的数据是 无差错的、有序的、无丢失的,简单的说就是:TCP最终递交给应用层的数据和发送者发送的数据是一模一样的。 采用的技术就是我们经常听说的 流量控制、拥塞控制、连续 ARQ 等技术来保证它的可靠性。
-
问:TCP 流量控制(GBN,SR)?
-
答:一般来说,我们总希望数据传输越快越好嘛,但是如果发送的过快,对方接受不过来,也很麻烦。所以这里的流量控制(Flow Control)就是让发送方的发送速率不要太快了,考虑对方的感受嘛。一般措施采用 滑动窗口流量控制 和 停止-等待流量控制,后者效率低,发一帧等回复,再发一帧再等回复。因此就有了滑动窗口,可以连续发好多帧,但是不能超过窗口,窗口不停的向前移动。其中发送方的窗口和接受方的窗口没有关系,可以任意,留给对方足够的空间才能长久相处。简单来看,滑动窗口有三种机制,当接受窗口 = 1 时,肯定按序到达。 停止-等待(ARQ):发送窗口大小 = 1,接受窗口大小 = 1; 后退 N 帧(GBN):发送窗口大小 > 1,接受窗口大小 = 1; 选择重传(SR):发送窗口大小 > 1,接受窗口大小 > 1;
-
问:TCP 拥塞控制?
-
答:其实需要从全局来看,若网络产生拥塞,网络的性能就要明显变坏,整个网络的吞吐量将随输入负荷的增大而下降。具体看下面的比较。
-
问:TCP 拥塞控制与流量控制的性质对比?
-
答:拥塞控制只有一个目的,使整个网络能够承受现有的网络负荷。是一个全局性的过程,涉及所有主机,所有路由器和降低网络传输性能的有关因素。而流量控制是在指定的发送端和接受端之间点对点通信量的控制,更具体,也很容易实现。而拥塞控制更关注全局,很难设计和实现。所以为了防止发生拥塞,TCP 要求发送端维护以下两个窗口一个和流量控制差不多,接收端窗口:根据接收端反馈的信息,来调整发送端当前能够发送的数据量,另一个是拥塞窗口:根据自己估计的网络拥塞程度,设置的窗口值,所以你能发送的数据肯定是二者中的最小值。以下是最常见的四种算法:慢开始算法,拥塞避免算法,快重传算法,快恢复算法,有兴趣可以自己翻书哦。
-
问:TCP 三次握手建立连接?
-
答: 我觉得图标的效果也没想象中好嘛,也不那么容易记忆。我们来讨论一下,为啥三次?如果只要一次就建立连接,假设客户端发送的请求丢失 [ SYN = 1表示我想建立连接, seq = x表示这是数据],那么客户端是不是死等也不会有人理他,所以不行的。那么两次呢,服务器端收到请求后,发送 [ACK=1接受你的请求,ack=x+1请再来点吧,SYN=1也请你和我连接吧,seq=y这是数据],如果这个请求丢失,两边是不是还是死等,而且傻乎乎也不知道对面情况怎么样了。所以最少要三次,最后客户端发送 [ACK=1我代表月亮接受你的请求,ack=y+1请再来点吧,seq=x+1这是你要的东西]。
-
问:建立连接会经过什么状态变化?
-
答:首先由客户端发起连接,客户端:CLOSED->SYN_SENT->ESTABLISHED, 服务端:LISTEN->SYN_RECV->ESTABLISHED
-
问:TCP 四次挥手释放连接?
-
答:其实如果理解了上面的三次握手,那么你可以把四次挥手理解为,建立连接时三次握手是一起建立的,你连接我,同时我也连接你了。但是断开不同了,因为可以不同时间,即如果我把数据先发完了,那么我就先断开了,我不能发,但是我能接受哇,你可以继续发,当你发完再结束。因此大致过程是:客户端[FIN=1客户端没数据了,我不发了,seq=x最后的数据],服务器端[ACK=1好的,ack=x+1真的木有数据了么,再来点呗,seq=y这是我的数据] 当服务器结束时:服务器[FIN=1好的吧,我也结束了,seq=w最后的数据,ACK=1知道你不发了,回我一下呗,ack=x+1给我发这个] 客户端[ACK=1好的,ack=w+1真没数据了?,seq=x+1给你] TCP连接必须经过2MSL后才真正释放。
-
问:关闭连接会经过什么状态变化?
-
答:客户端:ESTABLISHED->FIN-WAIT1->FIN-WAIT2->TIME_WAIT->CLOSED 服务端:ESTABLISHED->CLOSED-WAIT->LAST-ACK->CLOSED
-
问:只有执行主动关闭端才会出现TIME_WAIT?
-
答:是的。最后都会执行CLOSED。
-
问:CLOSE_WAIT 与 TIME_WAIT?
-
答:TIME_WAIT:即 2MSL,为了保证 A 发送的最后一个确认报文段能够到达 B,如果 A 不等待 2MSL,A 返回的最后确认报文段丢失,则 B 不能进入正常关闭状态,而 A 此时已经关闭了,也不可能再重传。(其次,进过 2MSL 可保证连接持续的时间内所产生的所有报文从网络中消失) CLOSE_WAIT:同上,只是这是 B 端需要等待关闭连接的时长。
-
问:【报文分组交换】方式是把长的报文分成若干个较短的报文组,【报文分组】是交换单位,它与【报文交换】方式有什么不同, 【报文分组交换】多了哪些东西?
-
答:报文交换:整个报文先传送到相邻结点,全部存储下来然后查找转发表,转发到下一个结点。 分组交换:单个分组(这只是整个报文的一部分)传送到相邻结点,存储下来后查找转发表,转发到下一个结点。 显然报文交换在存储过程中报文并没有被分割成多个分组,自然没有所谓的序号。
-
问:当应用程序使用面向连接的 TCP 和无连接的 IP 时,这种传输时面向连接的还是无连接的?
-
答:答案应该都是,因为这个问题就有问题,答案要从不同的层次来看,传输层是面向连接的,网络层是无连接的。
-
问:TCP 连接和网络的虚电路的区别?
-
答:TCP 是在传输层抽象的端到端的逻辑通信,记录连接状态,通过重发保证可靠传输,没有指定哪条线路,所以 TCP 连接是抽象的概念,就像咱俩是一根绳上的蚂蚱。虚电路是建立了一条线路,记录转发的路由器编号,下次依然是这些路由器转发,这个和真正意义上的连接更近一点。
- 特点:传送数据前无需建立连接,数据达到后也无需确认,不可靠,但是时延短。需要保证实时性的视频等,要用UDP连接。在传输层采用了 UDP 协议,其传输的可靠性则由上层应用决定。
- 问:既然传输层的 UDP 是不可靠的,为什么又说传输层提供可靠的服务?
- 答:某一层是否可靠,确实取决于这一层使用了什么协议。以前说数据链路层是可靠的,是因为它使用了 HDLC 协议,但由于一般链路上不会出现什么传输错误,就换成了无连接的 PPP ,所以现在数据链路层又是不可靠的,网络层也不可靠,因为使用了无连接的 IP 。那么现在这个重担就交给我们传输层了, UDP 不能保证数据报都能正确到达目的地, 发现错误之后选择丢弃或者反馈一个错误信息,但我们还有 TCP 啊,如果用户选择 TCP 就是可靠传输,我们默认传输层是可靠的。
-
问:下列关于UDP协议的叙述中,正确的是? Ⅰ 提供无连接服务 Ⅱ 提供复用/分用服务 Ⅲ 通过差错校验,保障可靠数据传输
-
答:I,II 正确 II 见 TCP 部分,III UDP提供检查和校验。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测,但检测到错误时,UDP不做错误校正,只是简单地把损坏的消息段扔掉,或者给应用程序提供警告信息。UDP的差错校验只是保证接收方接受的UDP数据包是正确的。而可靠传输的含义是:发送方发送的报文都能够正确无误的按序到达接收方。TCP 拥有可靠传输。
-
问:TCP/IP 为了高效率传输,传输层采用了 UDP 协议,其传输的可靠性由谁提供?
-
答:应用进程。我还以为问传输层的可靠性由谁提供,直接就写了 TCP。底层没做的,肯定交给上层 BOSS 啊。
-
问:若因特网上所有链路传输都是可靠的,那么使用 UDP 协议能实现可靠传输?
-
答:错误。就 拥塞控制 来说,即使所有链路是可靠的,但如果注入网络的数据太多,网络处理不了,也要丢弃部分数据,因而不能实现可靠传输。
-
问:TCP 和 UDP 的端口是相互独立的?
-
答:封装时包头信息不一样,任意帧在网络上可以区分出是 UDP 包还是 TCP 包,所以即使IP 地址和端口相同,也不会导致冲突。
-
问:可以用哪个命令来查看 TCP 和 UDP 连接状态??
-
答: netstat: 命令的功能是显示网络连接、路由表和网络接口信息,可以让用户得知有哪些网络连接正在运作。 使用时如果不带参数,netstat 显示活动的 TCP 连接。 ping: 命令可以检查网络是否连通,可以很好地帮助我们分析和判定网络故障 ipconfig: 当使用 ipconfig 时不带任何参数选项,那么它显示每个已经配置了的接口 IP 地址、子网掩码和缺省网关值。 nslookup: 命令用于查询 DNS 的记录,查看域名解析是否正常,在网络故障的时候用来诊断网络问题。
-
问:TCP 和 UDP 的比较?
- 对比 UDP TCP 是否连接 无连接 面向连接 是否可靠 不可靠传输,不使用流量控制和拥塞控制 可靠传输,使用流量控制和拥塞控制 连接对象个数 支持一对一,一对多,多对一和多对多交互通信 只能是一对一通信 传输方式 面向报文 面向字节流 首部开销 首部开销小,仅8字节 首部最小20字节,最大60字节 适用场景 适用于实时应用(IP电话、视频会议、直播等) 适用于要求可靠传输的应用,例如文件传输
- 总结 TCP向上层提供面向连接的可靠服务 ,UDP向上层提供无连接不可靠服务。 虽然 UDP 并没有 TCP 传输来的准确,但是也能在很多实时性要求高的地方有所作为 对数据准确性要求高,速度可以相对较慢的,可以选用TCP