拥塞控制

(滑动窗口)  大小决定   min( 接收窗口决定的 , 拥塞窗口决定  (发送方发送缓冲区大小))

why需要慢开始，最一开始发送方会将发送窗口(拥塞窗口的)设置的很小 ?

 

因为网络环境错综复杂，刚开始不清楚网络环境的好坏, 所以满开始就有点像是派个侦察兵去看看，网络环境咋样，然后再进一步调整拥塞窗口的大小   确定滑动窗口大小..

先探测一下当前的网络拥塞程度，然后由小到大的逐渐增大拥塞窗口的大小.

然后是指数级的扩张滑动窗口大小，但是也不能一直那样扩大下去，于是有一个阈值的概念，超过这个阈值又转变为线性增长了

当TCP开始启动的时候, 慢启动阈值等于窗口最大值

在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;

当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降

其实就是为了保证在不造成网络环境压力太大的情况下尽快将数据传输过去

TCP小结

• TCP是面向连接的，可靠的，基于字节流的传输层通信协议
• 如何保证可靠性:

• 性能提升上面：
• 1.  采取了滑动窗口
• 2. 快速重传 (不需要等待超时，三次对端提醒之后自动重传)

基于TCP应用层协议 HTTP HTTPS SSH Telnet FTP SMTP

TCP最大连接数的分析(面试常考)(从四元组的角度入手)

客户端   和  服务器之间建立连接  ：  只要确保客户端的 ip +  客户端的  port     两个中存在一个和服务端不同即可建立连接.....    

理论最大 ： 最大TCP连接数目  =  客户端ip数目  *  客户端端口数目

ipv4而言理论ip 数目最多是   2 ^ 32   port  数目是  65535 = 2 ^ 16,   所以理论最大的TCP连接数目是    2 ^ 48

但是并发数目是万万不可能达到上述这么多的.    (考虑并发) 首先第一个就是文件描述符的限制  sockfd数量限制，当然这个可以在服务器中修改配置...       ulimit

还有就是内存的限制了，TCP存在发送和接收内核缓冲区, 你用户空间也还要开缓冲区，所以肯定是无法达到上述哪个恐怖的数目的

四. UDP协议

• 先从报文分析入手

源端口号：  客户端端口号.

目的端口号：服务器端口号， 负责确定交付给哪个应用程序.

一个应用程序可以绑定多个端口号，但是一个端口号一定是对应一个应用程序.(端口号标识唯一应用程序)

16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度

如果校验和出错, 就会直接丢弃

报头理解, 报头实现地方式, 使用Ｃ语言中地位段进行理解：  多少位分为一段

UDP的特征:  什么是无连接，不可靠，关键为什么它如此的不稳定但是在现在的短视频 音视频通话 DNS  ARP这些全部都还使用的是UDP作为传输层协议

首先是无连接, 连接是什么:   连接算是一端到另外一端的不存在的一根线 (抽象的来说，这个是我的个人理解, 连接的过程也就是三次握手的过程)对于三次握手不理解的可以看我前文链接存在详解

首先不论是有连接还是无连接,    我们核心应该确定的是什么?    确定四元组，对了四元组，无连接也可以进程间通信，只不过每一次必须传入四元组, 但是口说无凭, 咱看看接口呗。对比一下:

为什么UDP是不可靠连接?

因为UDP没有TCP的哪些为了保证可靠性的机制:   比如超时重传机制，拥塞控制，流量控制机制，为数据包编号排序等...

思考为啥UDP如此不可靠我们还必须要使用它, 而且还会尽量的使其变得可靠, 还要专门做UDP可靠性设计，这个不是多次一举吗. 不如直接使用TCP?

首先解释UDP相比TCP为什么相对实时性好, 在时间上更短, 更加快速。。。

以上是从不必要的三次握手建立连接上解释这个速度问题, 为啥UDP更快

而且在进行数据传输的时候TCP还会存在一定的时间限制，时间阈值，超过这个时间就需要进行重传， 重传也会导致延迟性，向我们的qq聊天呀就经常出现这样的延迟现象，很明显底层应当是采取的TCP作为传输层协议.

根据上述的延迟解释一下音视频通话为例解释下为啥使用UDP而不是TCP？

一句话解释：就是通话延迟的问题，我们qq上发个消息是无所谓，延迟下我们可以等会看嘛，但是你在跟别人搞音视频，像抖音这些，或者各种视频，这个要是通话延迟，几秒前说的话几秒后出来了你这个还搞个屁呀, 还说得清嘛，这个很明显需要实时通话，正是这样的场景存在所以UDP必然是需要的。。。而且现在音视频（短视频）如此火爆更是少不了UDP了

我们再从另外一个角度来分析一下这个问题, 服务端压力上面来考虑。。。

再谈UDP可靠传输的设计。。。  

• 现有的udp可靠传输协议就是KCP了，感兴趣的还真有必要得去深入研究一下，我个人是研究深度还不够，先暂且浅显的聊一聊这个UDP可靠传输设计的一些基本的东西，KCP要是将来我的理解深入足够会尽力刨析一下...

• 首先既然提到了MTU  先解释一下  MTU是个啥玩也.

总结UDP可靠传输的学习:

多研究TCP协议的实现

设计  udp可靠传输，和TCP不一样，重传策略受到我们的控制可控  (也不一定所有都需要重传)  像音视频，游戏走位 超时太久丢包就丢了，不需要重传...  但是有些其他应用场景下又必须进行重传

重传时机的确定 （根据具体的业务需求去设计，不要一味追求设计一个通用性的UDP可靠传输协议）

五.   对比TCP和UDP的细节

连接    

 

TCP是面向连接的传输层协议，传输数据前需要先建立连接

UDP 是不需要建立连接的。 即可马上立即传输数据 (接口传入二元组)

服务对象

TCP是一对一的两点服务，即一条连接只有两个断点

UDP支持一对一 ，一对多， 多对多的交互通信

可靠性

TCP是可靠交付数据的，数据无差错，不重复，按顺序到达

UDP则是尽力交付，不保证可靠 (因为没有各种传输策略)

总结本文

• 本文从再看HTTP  和  对比学习   HTTPS入手
• HTTP协议的学习核心在于搞清楚他是一次性的无状态连接方式，连接建立之后服务结束立马断开连接。。。  
• 还有就是搞清楚HTTP的报文格式

上述的核心在于最开始的一行请求行 (请求方法  URL  协议版本) +   状态行(协议版本  状态码  状态码描述字段)   搞清楚空行的作用：分割报头和正文

HTTPS对比 HTTP学习  :  一个是明文传输的角度来看  另外一个是从网站真实性，身份验证，中间数据修改  的角度来看去分析，HTTPS相对 HTTP多了SSL加密层

然后是UDP和TCP的学习：

UDP无连接的  基于一个一个数据包的传输的一种 不可靠传输协议  （但是因为其相对TCP的快速 （实时性更好） + 可制定各种传输策略实现可靠传输 ）在音视频通话等领域有着不可替代的作用

TCP有连接的 基于数据流的可靠传输协议  (可靠的核心在于各种策略机制)