一看就懂TCP
Dm同学
博观而约取
展开
-
一看就懂TCP-总结
对比UDP: TCP并不是对所有的应用都适合,一些新的带有一些内在的脆弱性的运输层协议也被设计出来。比如,实时应用并不需要甚至无法忍受TCP的可靠传输机制。在这种类型的应用中,通常允许一些丢包、出错或拥塞,而不是去校正它们。例如通常不使用TCP的应用有:流媒体、网络游戏、IP电话(VoIP)等等。任何不是很需要可靠性或者是想将功能减到最少的应用可以避免使用TCP。在很多情况下,当只需要多路复用应用服务时,用户数据报协议(UDP)可以代替TCP为应用提供服务. 参考内容: ...原创 2020-09-27 12:03:15 · 150 阅读 · 0 评论 -
一看就懂TCP-快速之拥塞控制
再来想想这个窗口的大小 还会和什么有关系? 除了接收方的能力之外,还和网络 带宽有关 ,但这个TCP 怎么能动态的知道网络的情况呢? 如果我们设置发送窗口,使得发送但未确认的包为为通道的容量,就能够撑满整个管道。 如图所示,假设往返时间为 8s,去 4s,回 4s,每秒发送一个包,每个包 1024byte。已经过去了 8s,则 8 个包都发出去了,其中前 4 个包已经到达接收端,但是 ACK 还没有返回,不能算发送成功。5-8 后四个包还在路上,还没被接收。 这个时候,整个管道正好撑满,在发送端,已发.原创 2020-09-27 12:01:35 · 253 阅读 · 0 评论 -
一看就懂TCP-快速之流量控制
如果接收方没有 及时回复,发送方就要干等着,接收方回复。这样报的往返时间越长。怎么改进呢?我们让他在一段范围内,无需等待确认应答,而可以继续发送数据。 这还是用我们提到的缓存。发送方 在等到确认应答返回之前,必须在缓冲区中保留已发送的数据。如果按期收到确认应答,此时数据就可以从缓存区清除。也就是可以并行发送。那么这个量是多少呢?也就是TCP里的窗口? 窗口的大小取决于什么呢?首先想到的一点就是取决于接受方。接收端的数据先在缓冲区,缓存区的大小是一定的。缓存区里 存放这已经成功接收的数据 待还没被应用层..原创 2020-09-27 11:54:43 · 257 阅读 · 0 评论 -
一看就懂TCP-不丢
不丢数据 丢失数据需要重传,那这个重传的时间应该是多少呢? 我们来分析下这个情况: 所以我们的结论应该是 再仔细分析: 这个公式可以忽略,但需要记住一点,如果超时重发的数据,再次超时的时候,又需要重传的时候,TCP 的策略是超时间隔加倍。但是这样超时周期可能相对较长。那是不是可以有更快的方式呢? 在上图,发送方发出了 1,2,3,4,5 份数据: 第一份 Seq1 先送到了,于是就 Ack 回 2; 结果 Seq2 因为某些原因没收到,Seq3 到达了,于是还是 Ack 回 2; 后面的 Se.原创 2020-09-27 11:34:47 · 173 阅读 · 0 评论 -
一看就懂TCP -有序
源端口号、目的端口号:数据从哪来发送给哪个应用 序号:包编号能解决乱序问题,表明先后顺序。 确认序号:发出去的包应该有确认,如果没有收到就应该重新发送,直到送达。 每个 连接 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区。缓存区里是有序排列的。 ...原创 2020-09-27 11:23:39 · 385 阅读 · 0 评论 -
一看就懂TCP-连接
我们先来看一个定义。 这样理解比较抽象。我们换个角度。 它的本质还是传输控制。如果让我们自己设计这个传输,我们会怎么想呢。 TCP 协议它会先建立连接。 三次握手目的是保证双方都有发送和接收的能力 首要原因是为了防止旧的重复连接初始化造成混乱。 同步双方初始序列号客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口,处于 LISTEN 状态。然后客户端主动发起连接 SYN,之后处于 SYN-SENT 状态。服务端收到发 起的连接,返回 SYN,并且 ACK 客户端的 SYN,之后处于原创 2020-09-27 11:20:13 · 172 阅读 · 0 评论 -
一看就懂TCP-前言
前言: 当我输入 www.jd.com 发生了什么? 先在浏览器里面输入 https://www.jd.com ,这是一个URL。 浏览器只知道名字 是“www.jd.com”,但是不知道具体的地点,所以不知道应该如何访问。于是它打开地址簿去查找,是互联网世界的“门牌号”。 知道了目标地址,浏览器就开始打包它的请求。 DNS、HTTP、HTTPS 所在的层我们称为应用层 经过应用层封装后,浏览器会将应用层 的包交给下一层去完成,通过 socket 编程来实现。 下一层是传输层 TCP 协议里面会有两个原创 2020-09-25 19:11:14 · 170 阅读 · 0 评论