美文网首页
计算机网络小结

计算机网络小结

作者: 看谷秀 | 来源:发表于2022-03-03 20:26 被阅读0次

    计算机网络

    2022/0221

    一 网络协议& TCP/IP网络协议

    网络协议.png

    二 数据链路层

    主要信道:
    1 点对点通信信道(一对一)
    2 广播信道(一对多)
    数据部分长度上限: 最大传输单元MTU(Max Transfor Uint)


    数据链路层.png

    三 网络层

    数据报传输格式 IP数据报


    ip数据报.png

    1 版本 指定通信双方IP协议版本要一致(ip协议 ipv4或是 ipv6)
    2 首部长度: 首部= 固定20字节 + 可变部分 首部长度记录了首部总长度(可变部分不是变化的么)
    3 区分服务: 区分服务时候才会用,平时不用
    4 总长度: 总长度= 首部长度 + 数据部分长度 16位即为16个1, 10进制数就是2^16-1 = 63535个字节 64kb5 标识: 下层传送切片相关, 数据报,数据部分太长时候, 给下层的数据链路层传送时候需要分片,用这个记录标识(ip数据报不用建立连接,所以也不需要,标识需要传送)
    6 标志:下层传送切片相关, 1为还有切片,0 为没切片了
    7 片偏移:下层传送切片相关, 标记重组位置
    8 生存时间: 超时了,就丢弃这个ip数据报
    9 协议: 定义运输层使用什么协议 TCP/UDP啥的
    10 首部检验合: 检验数据报首部(注意: 不检验数据部分,因为每经过一个路由器,时间,标志,位移都可能发生变化)
    11 可选字段:扩容字段,排错,测量,安全啥的

    Ps: 10为啥不检查数据部分,效率被

    四 运输层/传输层

    UDP 用户数据报协议


    udp数据报.png

    Udp的数据报的数据长度是 64kb 16位就是16个1

    一: udp对比ip数据报增加功能
    1 分用复用功能
    2 检验和功能(ip数据报只是检验首部, 不检验数据, udp全检验)

    二: UDP特点
    1 udp无连接 (为了减少开销, 不需要建立连接和释放)
    2 udp尽最大可能交付(不保证可靠交付, 因为没有维持复杂的连接状态)
    3 udp面向报文
    3.1 应用程序交下来的报文段, 添加首部就交给IP层, 封装成ip数据报, 就是tm在添加个首
    3.2 运输层接收到网络层的Udp数据报, 也就是去掉udp首部上交给应用层
    4 udp没有拥塞控制 (网络的拥塞,不会降低主机的发送速率降低, 对于某些应用, 需要恒定的数据发送速率, 而且网络拥塞时候, 不能有太大的延迟,用udp正合适, 例如ip电话或是实时视频会议)
    5 udp支持一对一 , 一对多, 多对一, 多对多.
    6 udp首部开销小(8个字节, tcp20个字节, 使用不适用拥塞控制功能的udp, 会是多个主机都以恒定的速率发送数据, 导致网络拥塞)

    数据报 = 数据报头部+ 数据报 组成 支持最大传输数据是64kb. 怎么来的呢
    数据报头部定义的 你的长度留出来几个字节存储, 例如8位 则最大长度是8个1, 换算10进制长度就是多少个字节

    1 源端口号: 源端口号(当前主机ip地址+ 端口号) 需要对方回信选用, 不需要时候可用全0
    2 目的端口: 目标ip地址 + 端口号
    3 长度: 数据报长度
    4 检验合: 检验传输过程是否有错,否则丢弃
    5 伪首部: 检验合时候用, 不向上或是向下传递

    三: TCP 运输层数据段传输格式

    tcp协议.png

    四: tcp 首部
    (15)选项: ?? 规定了tcp数据报的长度(数据报总长度包括首部20字节+ 数据报长度), 原则上是越大越好,但是呢,要避免数据链路层ip数据报承载,被切片传送的限定为佳

    首部: 固定 20个字节 160位 + 选项 + 填充(非固定)

    1 源端口: 需要对方回信本主机ip地址 + 端口号, 否则全0, 分用复用通过端口实现 (分用: 从下自上,传给各个应用层的进程,反之从上向下,多个进程传出去)
    2 目的端口: 目标ip地址 + 端口号
    3 序号: 存的是本段报文段所传送的字节流的第一个字段的序号, 范围(1 ~ 2^32-1), 报文段序号, 字节流是按序编号的,
    4 确认号: 存的也是序号, 期望接收到的序号 (例如: B上次传过来A的序号是301,数据长100字节,下次序号该400了, 则B期望A下次传过来的是400)
    5 偏移量: 标记数据段首部距离 tcp数据起始多远,标记的是数据报首部长度 (除了20自己固定的首部长度, 还有选项部分嘛)
    6 保留: 保留为日后使用,目前置为0 ?? 不知道毛意思
    7 URG: 紧急, 标志,数据段中有紧急数据,优先处理,交付到应用层 (正常要等到数据缓存在tcp缓存尾部,才会依次处理),URG为1时候,将紧急数据插入到本报文段的最前面
    8 ACK: 确认 为1 报文段有效 tcp规定建立连接后, ACK为1时候才有效
    9 PSH: 推送 为1 报文段尽快被处理,不用等到TCP缓存存满之后才处理 (ps感觉优先级比紧急低呢)
    10 RST: 复位 为1 代表TCP建立了错误连接, 需要释放连接, 然后重新建立连接
    11 SYN: 发起建立连接请求报文段 为: SYN为1, ACK为0, 若同意连接,则响应报文段使用 SYN为1 , ACK为1 建立新的连接
    12 FIN: 为1 标识需要释放一个连接 (例如报文段数据发送完毕)
    13 窗口: 指的是发送报文段一方的接收窗口 (注意此时他是发送方,但是描述的是他接受的能力), 描述了一个发送发的接收数据的能力
    14 检验和: 检测数据正确性包含 数据段首部 + 数据段数据 ,计算检验和字段时候开启伪首部
    15 紧急指针: URG为1时候才有意义,标记了URG的位置
    16 选项: 如果没使用选项时候, TCP首部长度为20个字节 160位

    Ps: 序号补充: 例如序号存的是301, 数据是100字节, 表示,本段报文段第一个字节需要是301 ,最后一个字节序号是400,下一个报文段的序号就要401开始了.

    五: 复用和分用
    复用: 应用层的各个进程是通过运输层在传导IP层的这叫复用
    分用: 运输层从IP层收到发送给各个应用进程的数据,必须分别交付给指明的各个应用进程, 叫分用

    六: 进程
    进程: 应用层的进程使用一个不大不小的数字表示的, 具体表示用端口号
    Tcp/ udp 协议中有源端口号, 和目标端口号, 表示源主机的某个进程, 到目标主机的某个进程 (相关协议端口协议)
    所以通信的双方, 需要知道源主机的ip地址(哪台主机), 端口号(表示哪个进程), 目标主机IP得知和端口号也一样

    七: 端口分类
    一 服务端端口号

    熟知端口号.png

    1 熟知端口号 (标记服务端进程)
    数值 0~1023之间

    INNA(www.inna.org)指派tcp/ip 一些重要应用程序的端口号(熟知端口号的应用程序) 例如 http:端口号80 https: 443 dns: 53

    2 登记端口号 (标记服务端进程)
    不是熟知端口号应用程序使用的, 需要在INNA按照规定手续登记,防止重复, 数值 1024~ 49151

    二 客户端端口号
    数值45152 ~ 65535
    客户端运行时动态选择, 也成端在端口号, 客户端服务端通信结束,这些端口号就不存在了,可以给其他进程使用

    ps: 暂时理解为 端口代表一个应用程序吧 !!!!! 存疑~~

    一 tcp特点
    1 面向连接的运输层协议, 使用tcp协议前,需要建立连接,传输结束需要释放连接

    2 每条tcp连接只能是, 端点到端点连接 (端点为套接字socket = IP地址 + 端口号)

    3 tcp协议可靠交付, 无差错, 不重复, 不丢失, 按序到达

    4 tcp采用双工全通信, 就是tcp通信的连段通信过程中既可以处理发送和接收, 同时有发送缓存和接收缓存

    发送时候: 应用程序把数据通过端点(socket)传送给tcp的发送缓存, 合适时间,处理发送,
    接收时候: 数据通过接收端端点(socket)存放在tcp接收缓存, 应用程序合适的时候, 读取接收缓存

    5 面向字节流, 流是指流入或是流出进程的字节序列, 应用程序和tcp交互是一个个数据块(大小不等), tcp把应用程序交付的数据块看做是一个个无结构的字节流

    二: tcp连接
    每条tcp有两个端点, 端点叫套接字(socket)或是插口
    套接字: 端口号拼接到IP地址构成套接字 例如IP地址为192.168.1.1 端口号为80(http应用)则套接字为192.168.1.1:80, 套接字 = (ip地址: 端口号)

    tcp连接 :: = {socket1, socket2} = {IP:port1, IP: port2}

    三: 可靠传输的工作原理
    首先tcp所在的运输层下面的网络层, IP数据报是不可靠的传输, 尽最大努力传输, 怎么保证tcp可靠传输呢

    1 传输通道不产生差错
    2 发送方不管多快发送, 接收方都来得及处理
    (实际条件不会满足上述两点)

    1 传输发生差错, 让发送方重传差错数据或超时重传
    2 当接收方来不及接收数据处理时候, 通知发送方降低速率(通过调整接收方窗口调节)

    停止等待协议.png

    例如 客户端A——服务端B 之间数据传输 (5-9 a)
    1 正常数据发送流程 A发送数据, B确认数据, A再发,B在确认…..

    2 解决发送失败重传流程(发送报文失败, 客户端问题 5-9 b)
    Tcp协议 解决差错数据, 每次发送数据都会有个超时计时器
    例如 当数据发送失败, 或是B检测出错误数据报, 啥也不做,等着超时重传就行了
    2.1 A发送报文(保存发送数据分组的副本,超时重传时候用),数据分组被服务端确认后, 清空副本
    2.2 区分哪个数据分组收到与否, 需要给数据分组编号(序号)
    2.3 超时重传计时器会比正常发送数据时间长一点

    确认丢失迟到.png

    3 确认丢失或是迟到(说的是服务端 数据接收)
    (5-10 a)的情况, B确认请求在A超时重传计时器之间延迟, 则A进入超时重传, 重新发送数据M1, B重新发起确认请求并且丢弃重复的M1数据
    (5-10 b) 的情况 B确认请求在A超时重传计时器之外延迟, 则A进入超时重传, 重新发送数据M1, B重新发起确认,A发起了新的数据M2,此时M1数据确认才到来, 则A啥也做

    四 发送数据原理(连续ARQ协议)
    发送方维持发送窗口, 等待接收方确认

    ACQ原理.png

    注意: 接收方采用累积确认方法, 不会对每个分组逐一确认(2就是一个分组),如图接收到五个分组后再确认, 当然如果出错了,例如5个分组中少了2个分组,则五个分组重新传

    五 Tcp可靠传输实现

    TCP缓存及窗口关系.png
    接着滑动窗口讲, 首先发送方窗口长度是由接收方决定的, tcp首部有窗口字段,所以发送方的窗数值不能大于接收方的窗口值

    问题1: 若报文段无差错, 但是序号有问题, 或是缺了中间序号
    方案: 通常是先存在接收缓存窗口里面, 等缺失的字节收到后, 在上传到应用层

    问题2: 怎么处理缺失中间序号的报文段
    方案: 接收到数据序号不连续时候, 告诉发送方哪个需要重新传, 接收过的, 可以不必再重新传了
    固定tcp首部字段中没有能标识序号错乱处理边界的字段, 所以会在首部选项字段(长度可变)中新增允许SACK字段, 允许存储无序序号处理

    六 超时重传
    采用自适应算法
    发送数据时间到接收数据确认时间, 时间差称之为 往返时间RTT, 这个重传时间是动态计算出来的

    七: TCP运输连接管理(三次握手 这Tm是重点)

    Tcp三次握手.png

    建立连接流程
    1 A 发送请求连接报文段 (不能携带数据)
    2 B 对A的请求报文段确认 (不能携带数据)
    3 A收到B的确认请求, 给一个再确认 (可以携带数据)

    问题1 按说两次握手就能建立连接了,为啥客户端还要再次确认呢?
    例如 (处理极端的错误)
    客户端A 和服务端B建立连接
    A发送了两次建立连接请求, a1, a2 ( a1由于网络原因, 延迟了)
    a2正常连接,传数据后,释放结束了
    本来失效的报文段a1 刚发送到B客户端,B以为是A重新建立的连接呢,像A发起确认请求,再次建立连接,如果不采用第三次握手,B发起确认,连接就建立了
    A没有发起建立连接,所以不会去处理B的确认请求,也不给B发送数据,B却以为连接已经建立的, 一直在等待A发送数据呢,资源浪费.

    哄咔嚓哄咔嚓

    八: TCP释放连接 (四次挥手)

    四次挥手.png
    MSL:最长报文寿命
    1个MSL建议设置为2min

    问题: 为什么要等待2MLS时间呢??
    如果你能保证客户端A最后一次发送的确认请求一定发送成功, 那就可以,现实肯定是不可能的
    否则, 需要延长一点时间, 服务端B没有收到客户端A的确认请求,会重新发起断开请求,这样才能保证客户端A接收到

    ps: 客户端A发送确认就断开的前提是, 保证这次发送确认一定能成功, 否则就需要留着TCP连接通道, 给服务端发送重新断开请求留下通道, 让客户端能再次确认

    保活计时器
    服务端设计的
    例如Tcp连接后, 客户端故障没办法发送数据给服务端, 客户端每发送数据给服务端, 则服务端重置一次保活计时器默认2小时, 2小时没收到数据, 则75秒发送一次探测报文段给客户端, 发送10次,如果还是没有响应, 则认定客户端故障, 关闭tcp连接

    习题:
    \color{red}{1: 运输层在协议栈中的地位和作用?}
    \color{red}{ 输层和网络层通信有什么重要区别?}
    \color{red}{为什么运输层必不可少?}
    运输层提供了进程之间的逻辑通信, 向应用层屏蔽了下面网络层的细节(路由选择协议等)看着像是两个进程之间好像在运输层有条实体传输通道一样
    网络层是主机之间的通信 (ip地址主机到 ip地址主机), 运输层之间通信是为应用层提供端到端的逻辑通信(socket到socket)

    \color{red}{2: 哪些应用使用的无连接的UDP, 不使用TCP连接}
    Ip电话, 视频会议

    \color{red}{3: UDP接收到有错的数据怎么处理}
    Udp有检验和字段, 创建伪首部, 检测udp头部和数据部分, 发现有问题数据直接抛弃

    \color{red}{4: 应用程序使用UDP完成可靠传输可能么? 理由?}
    需要解决
    1 确认机制 ,发送方发送,接收方收到给个确认
    2 重传机制 ,超时没有确认的的需要重传
    3滑动窗口, 保证窗口接收,我发送的快了慢了能调节接收窗口大小
    1.2 属于传输正确性范畴, 3属于传输调节问题
    传输层无法解决只能搬到应用层处理
    开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

    \color{red}{5: 运输层伪首部什么作用?}
    检验数据报正确性, 包含报文段首部, 和数据

    \color{red}{6: 为什么UDP面向报文, tcp面向字节流?}
    1 UDP是面向报文的 发送方应对, 应用层传下来的报文, 不拆分, 不合并, 加上首部交给网络层, 也就是说不管大小, 从应用层传给传输层
    接收方接应用层接收来自udp的报文, 去掉首部, 发送给应用程, 所以控制报文大小, 是靠应用层处理的
    2 Tcp和应用层交互是一个个数据块, tcp把这些数据块把这些数据块看成是一个个字节流, 通过发送窗口发送, 接收窗口接收

    \color{red}{7: 端口号是什么, 为什么用端口号划分三种}
    端口号: 表示一个应用进程, 使不通操作系统的计算机之间可以通信
    标记服务端进程的熟知端口号, 和非熟知端口号, 客户端端口号(临时的)
    \color{red}{8: 运输层的伪首部什么用}
    计算检验和 检验头部和数据部分正确性的, 不参与向下传输或是向上传输

    \color{red}{9: udp数据传输和 ip数据报传输的区别}
    1 udp新增了分用,复用功能
    2 增加了检验数据部分和首部(ip数据报仅仅检验首部正确性)

    \color{red}{10: tcp与udp的区别}
    ① 基于连接与无连接(是指传输数据之前)
    ② 对系统资源的要求(TCP较多,UDP较少)
    ③ UDP程序结构较简单,首部开销只有8个字节,而TCP有20个字节。
    ④ 流模式与数据报模式,UDP没有拥塞控制,UDP中当网络发生拥塞不会使源主机的速率降低,
    多用于实时应用中,如IP电话,实时视频会议等。
    ⑤ TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。
    ⑥每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。
    ⑦ TCP的逻辑通信信道是全双工的可靠信道(及时发送方也是接收方),UDP则是不可靠信道。
    ⑧ TCP多用于传输大量数据,UDP多用于传输少量数据

    五 应用层

    一 DNS

    域名.png

    DNS: 域名系统是互联网的一个服务
    域名和ip地址映射的数据库
    例如: www.baidu.com 对应 ip地址192.168.1.1 根据域名去dns服务器解析出对应的ip地址, 从而使主机可以和另一台(已知域名的主机)可以数据连接

    清华大学邮箱域名: 如图 mail.tsinghua.edu.cn (这样在全球internet中有了一个唯一地址)
    域名和主机的IP是一一对应的关系

    PS: 这个DNS服务,就是通过DNS服务(包含许多域名解析服务器)解析出对应主机的ip地址的服务

    二 FTP
    FTP: 文件传输协议
    解决实际问题: 例如一台主机从另一台主机上获取文本文件(txt文件)

    FTP协议.png
    工作流程: 文件传输时候, ftp客户端创建两个并行tcp连接, 控制连接和数据连接, 通话期间两个连接都都保持打开状态
    1 控制连接: 控制连线, 和给服务端发送控制进程
    2 数据连接: 负责传输数据

    三 TFTP: 简单文件传输协议
    采用UDP传输

    ** 四 万维网**

    万維网站点.png
    万维网是一个大型的连接式的信息储存所
    万维网具体是用链接的方式, 可以从互联网上由一个站点访问另一个站点, 主动的获取信息
    从一个连接, 访问到一台主机存储的信息, 审阅呀, 下载文件等

    一 URL (统一资源定位符)
    1 概念: 表示 得到互联网资源的位置及访问资源的方法
    资源: 包括目录文件, 图像, 音频, 视频

    二 URL组成
    协议:// <主机>:<端口>/<路径>
    协议:// 什么协议 例如 http(超文本传输协议) ftp(文件传送协议)
    端口http为80 路径 有时候可以忽略不写

    例如 baidu.com 输入浏览器后, 会被自动补齐 http://baidu.com

    下图是http协议的url


    url.png

    路径后缀的index.html为html编写出来的文件
    PS: URL里面不区分大小写
    Ps: 这个主机域名写ip地址也ok吧 ~~~~~!!!!

    三 HTTP
    概念
    http 定义了浏览器怎么向万维网服务器请求万维网文档, 万维网服务器怎么把文档传给浏览器
    主要是交换资源(文件, 声音, 视频, 图像)

    http连接.png
    第三次客户端发送收到确认请求时候, 把http请求带给服务器, 服务器接收到请求报文, 回复响应报文

    http/1.0(非持续连接)(如上图) 每次访问服务器都需要, 时间是2rtt时间的开销
    Http1.1 (持续连接 http1.0升级版) 就是服务端发送了响应报文后, 都会保持连接一会, 所以客户端只要再次访问这个服务器时候, 都不需要在浪费两次rtt开销了,可以直接发送请求/响应报文交互数据了

    http1.1分两种 非流水方式 流水方式
    非流水方式: 客户端发送请求报文后, 得到服务端的响应报文后, 才能发新的请求报文
    流水方式: 客户端发送请求报文后, 在的到服务端的响应报文前, 可以发送新的请求报文(效率更高)

    四 代理服务器
    概念
    就是缓存了之前一些请求和响应在本地磁盘, 代理服务器发现新的请求存在缓存中, 就返回暂时的响应, 不需要用url去互联网访问该资源

    代理服务器.png
    ps:代理服务器, 就是泥马缓存请求和响应, 代理服务器没有当前请求,则作为客户端发请求向源点服务器请求资源, 有的话作为服务端给校园网浏览器发送响应请求

    五 HTTP报文结构(重点)
    下图 请求报文& 响应报文
    1 组成分为三部分
    (1 )开始行 区分请求行还是状态行(请求行/ 状态行) CR(回车) LF(换行)
    (2) 首部行 说明浏览器, 服务器或是报文主体信息
    (3) 实体主体: 请求也好,响应也好一般不写这个报文

    ps: 请求行 请求头 请求体/ 响应行 响应头 响应体

    http结构.png
    2 请求报文
    请求行
    方法(get post) url: 统一资源定位符号(协议://主机/端口号/路径) 版本: http版本
    HTTP 请求报文的一些方法.png
    请求报文(全….下图)
    HTTP 请求报文的例子GET.png
    上图: 首部字段名: 值(回车换行)HOST(首部字段名) : ww.xyz.edu.cn(值) ,这个请求没有实体主体
    ps: 包含请求行, 首部行, 没有主体实体(上图)

    3 响应报文


    响应报文.png

    响应行
    版本 状态码 短语 例如 HTTP/1.1 202 Accept {接受}


    响应行.png
    响应报文 (全….下图)
    响应报文.png

    ps: 包含响应行, 首部行, 没有主体实体

    六 服务器存储用户信息 (Cookie)
    概念: 浏览器用cookie标识某台主机, 目的记录浏览器的用户的行为

    浏览器访问服务器, 则服务器给浏览器生成一个cookie, 发送响应报文时候追加一行首部行 Set- cookie: 123456

    浏览器接收到服务端响应报文中cookie,缓存, 下次发送服务端请求报文时候,同样首部行添加 Cookie: 123456给服务器

    七 万维网文档
    就是这个网页咋写出来的 h5 cs js 写的

    超链接: 需要先添加个Url, 要不你点击咋跳转的, 没那么神奇

    八 收发邮件
    发送邮件SMTP协议
    接收邮件POP3 IMAP协议

    \color{red}{问题1:Get Post 区别}
    get请求数据部分拼接在url后面(那就是在请求行中体现), 一般不包含请求体, 地址中可以看见参数, 由于浏览器限制url长度, 所以传递数据大小被限制

    post请求数据被封装在请求体中, 所以数据大小不被限制

    区别
    1 数据提交方式不同
    Get数据?后面拼接在url后面&连接, get数据封装在数据体中

    2 数据传输大小不同
    http没有规定url的长度, 但是浏览器规定了, IE 2048+35 = 2083字节, 所以get数据传输长度受限制
    Post理论上数据传输没有限制, 但是实际上各个web服务器, 对数据提交大小做了限制

    3 安全性
    Post安全性更高点, 因为浏览器缓存, 看历史记录就能拿到账号密码了

    相关连接
    https://www.cnblogs.com/lauhp/p/8979393.html

    \color{red}{问题2:socket}
    socket组成:
    IP地址 + 端口号 (tcp通信的两个端点)

    socket的作用:
    应用层通过传输层数据通信时候, 计算机操作系统为应用程序与tcp/ip协议交换提供了成为套接字(socket)的接口, 区分不通程序之间的网络通信

    socket连接步骤
    1 socket服务端监听 -> socket客户端发送请求 -> socket连接确认

    socket与http
    很多时候需要客户端服务端保持数据实时同步 (需要服务端主动向客户端发送数据)

    如果http需要客户端先发送请求报文, 才能获得客户端的响应报文

    但是建立socket连接后(tcp), 则客户端可以直接给客户端发送消息

    socket长连接
    首先tcp是有状态的长连接, 通常说的socket长连接就是tcp连接

    http属于短连接, 每次数据传输, 先建立tcp连接, 客户端发送请求, 服务端响应, 然后断开tcp连接.

    每一条Tcp连接有两个端点, 就是socket(接口)
    socket不是协议, 算是个对TCP/IP协议的封装

    Socket有两种连接方式
    1 面向udp的无连接的socket 2 面向tcp的有连接的socket

    ps: TCP/IP协议指的是四层网络协议

    \color{red}{问题3:UDP和TCP的区别}
    ①基于连接与无连接(是指传输数据之前)
    ②对系统资源的要求(TCP较多,UDP较少)
    ③UDP程序结构较简单,首部开销只有8个字节,而TCP有20个字节。
    ④流模式与数据报模式,UDP没有拥塞控制,UDP中当网络发生拥塞不会使源主机的速率降低,
    多用于实时应用中,如IP电话,实时视频会议等。
    ⑤TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。
    ⑥每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。
    ⑦TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道。
    ⑧TCP多用于传输大量数据,UDP多用于传输少量数据

    \color{red}{问题4: tcp/udp数据报长度限制}

    1 udp报文首部有包长度限制 64kb

    2 tcp报文首部没有包长度限制, 依靠ip层处理

    相关连接

    https://www.jianshu.com/p/947a2673102a

    https://www.cnblogs.com/aspirant/p/11334957.html

    https://blog.csdn.net/qq_35408439/article/details/73250532

    相关文章

      网友评论

          本文标题:计算机网络小结

          本文链接:https://www.haomeiwen.com/subject/ghmurrtx.html