面向字节流

如何理解面向字节流？
发送缓冲区，我们将它当做char类型的数组，当发送时他们的发送序号就可以从他们的下标来获取，接受缓冲区也是char数组，再一个一个字节的向上层读取。

如何理解流动的概念

我们的报文中从没有提到标识数据大小，当接收缓冲区接收到10个报文时，将他们的报头分离，他们的数据无法分离就都同时存储在接受缓冲区，当上方一个字节一个字节向上读取，接收缓冲区又一个字节一个字节的读入，这就是流的概念

超时重传机制 丢包

1.数据丢了

客户端过一段时间会重新发送信息

2.应答丢了

服务端也是过一段时间重新发送信息

但是不是服务端可能收到了两条一样的报文？如何处理？
去重，根据报文的32位序号
所以发送方会将发送的报文暂时保存起来，那么保存在哪里呢？滑动窗口之中

超时时间是多少呢？
网络状态是变化的
超时太久发送：效率太低
超时时间过短：访问次数频繁
所以超时时间一定是浮动的，我们的超时时间是以500ms为单位的，例如第一次超时重传是1500模式、第二次就是2500，第三次就是4*500，超出一定的重传次数，我们就直接断开连接。
  

  

连接机制

我们的服务器内肯定有很多连接，我们就要对这些连接组织起来，先描述再组织，

struct links{
int start seq;
std::string src ip
std:string dst ip
,int srcport/dstport;
uint64 t timestamp,
int status;
int urgdataptr; 
struct links *next
}

连接时有状态变化的

#define set_syn 1
#define rec_syn 2

我们通过管理这些状态宏，将link结构体中的status替换成相对应的宏，就有连接的状态了

三次握手

为什么要进行三次握手？
a.以最小成本验证全双工，验证通信通道是否顺畅
建立连接是需要建立结构体管理的，是需要时间加空间的成本的,tcp协议双方地位是对等的
1.如果是一次握手，那么双方都无法确定是否可以通信，因为只发了一次SYN，此时还会引发SYN洪水
2.如果是两次握手呢，服务端知道了建立好了到客户端的链接，但是由于没有客户端的应答，无法确定客户端是否收到syn请求，但是此时客户端是知道自己到服务器的连接和服务器到客户端的连接都建立好了，此时服务端发出去应答+syn就会误以为连接建立，但此时的连接时无法保障的，可能浪费了服务端的资源+时间，造成双方无法对等
下文中还会提到
b.会同步序列号 简单是说
序号:比如ISN为1000，下一字节的数据序号就为1001；
确认序号：接收方成功接收的字节的数据序号的下一个。
假设客户端的ISNc为1000，服务端的ISNs为2000，三次握手的过程如下： ISNs为双方的起始报文序号
1.客户端SYN：SYN报文起始序号为1000
2.服务端SYN+ACK：SYN起始报文为2000，ACK中确认序号就为1000+1=1001，对客户端SYN的应答‘
3.客户端ACK：确认序号为2001，对服务端SYN做出应答
依次类推，因为服务端上一次发送确认序号为1001，此时客户发送1000字节，此时1000的字节数据序号就是1001~2000，ASK报头中确认序号就要为最后一个字节的数据序号+1，ACK的确认序号就是2001。

c.规定初始的滑动窗口大小（后文提及）

d.奇数次握手，保证了客户端要先建立连接，服务器才建立.
  
  
新理解：
四次握手+捎带应答
100：互相都保证了对方受到了我们建立连接的请求
也就是说少了哪一条信息，我们都能知道我们双方是否完成建立连接

四次挥手

三次握手是为了确定双方都建立好了连接，是为了确定性，那么四次挥手是不是也是为了确定性，为了双方地位对等
  
可不可以出现三次挥手呢？    ACK+FIN
有可能，但三次握手不是主流，断开连接和建立连接是不一样的，建立连接是客户端主动建立连接，服务器被动接受，客户端一连接服务器，服务器就必须去连接，此时ACK+SYN就可以同时发送，。
断开连接是需要双方共同协商的，有可能当客户端发送FIN，但是服务器可你出现什么突发情况，不想去断开连接想继续向客户端发送数据，但是必须要回答，此时用ACK+FIN就不能完成这种场景。

四次挥手中的状态变化
  
CLOSE_WAIT:等待关闭，此时需要将通信套接字关闭
那么我们在断开连接中，不使用close函数，会发生什么？
服务器下会有非常多的CLOSE_WAIT,客户端接到ACK变成FIN_WAIT_2状态
  
当出现大量的CLOSE_WAIT状态,Linux系统网络应用越来越卡

主动断开的一方，会进入 TIME_WAIT 状态，这是一种等待的状态

让server主动断开,server进入TIME_WAIT？

server端的tcp会处于TIME_WAIT状态，等待一段时间后自动关闭，这个连接叫做尚未被彻底释放，也就是说此时端口号正在被使用，重启server，又要重新bind 端口号 ，此时就会报错:端口号正在被使用

client主动断开，为什么不会报bind端口号错误？
我们客户端绑定的端口是由操作系统提供的随机端口。

为什么要有Time_Wait？
许多教材中讲网络中会有尚未到达对方的报文，可是四次挥手都完成了，怎么还有报文未达到
有些历史报文可能是在网络传输过程中阻塞了，如在路由器中被阻塞。

那么在下一次建立连接时，未到达历史报文就发送到了服务器，那么就会对服务器接受报文造成影响。

Time_Wait就是在等历史报文进行消散，这样就能极大的减少对新连接的影响

为什么不是双方都进行Time_Wait?
主动断开连接的一定是有充足的时间等待报文全被发出去并达到，可是接受断开连接方就无法保证报文全部到达主动断开方
  
Time_Wait的时间是多少
2MSL
MSL:TCP报文的最大存活时间 centos版本是60s；
因为要让我们有可能接收到历史报文，还能有一次ACK的机会，所以是2倍

可是这样历史报文还是有可能对我们造成影响
a.双方采用随机序号，可是如果随机序号为1000，数据为3，发送给对方序号1003，可是对方如何对缓冲区进行管理，他又不知道报文数据的大小，那么怎么规划指针呢。

b.三次握手之中不仅仅是为了发送syn，随机序号是可以相互告知的，还会起始序号的协商，比如商量为1000，那么1003-1000=3，数据大小为3，就知道数据为3，将指针往后移动3位

c.即使旧的报文在网络中延迟很久后到达，也不会与新的连接混淆。这样序号发生冲突的概率变得更低了。

滑动窗口

并发的发送暂时不需要ACK的报文，从而提高效率
我们在上文中提到，发送报文是需要将报文保存起来的，方便丢失报文的时候重传，那么是存储在哪呢?
  
  

凡是在窗口范围内的报文可以直接发送，暂时不需要ACK
1.滑动窗口在哪里
滑动窗口是在发送缓冲区的一个区域
      
2.滑动窗口怎么理解
  
我们将缓冲区理解为一个char类型的数组，win_start和win_end中间的范围就叫滑动窗口。
滑动窗口的大小由谁决定？
目前：由对方接受缓冲区的接受能力决定
滑动窗口如何更新？
ACK会发送2个信息，一个是确认信号，另一个就是滑动窗口大小
newwin_start=确认信号
newwin_end=win_start+滑动窗口大小
最开始，我们还没有发送数据时，此时窗口大小应该为多大？
我们上文中提到三次握手会交换syn，和随机序号，其实还有初始的窗口大小。
3.滑动窗口向右移动时，滑动窗口会不会变小或变大？
当1-1000序号发送给对方的缓冲区，对方收到了返回ACK，返回序号为1001，但是接收缓冲区的数据未被读取，此时start指针向前移动，窗口大小就为3000。后文中还会提到因为拥塞控制使窗口变化，窗口大小是一直变化的。
  

滑动窗口会滑出去产生越界问题吗？
将发送缓冲区想象成环形队列

4.其他
  
报文丢失怎么办？
最左侧报文丢失
如果是最左侧报文丢失，例如1-1000丢失 那么1001-2000的ack 2001-3000的ack 3001-4000的ack的确认序号是多少呢？
我们重申一下概念：确认序号是在该序号之前的所有数据都收到了，那么如果1001-2000的ack是2001，这样的话我们2001前面的数据我们都收到了，但是1-1000的数据都丢了啊，所以1001-2000的ack只能是1001,2001-3000的ack肯定也不能是3001，所以只能是1001，我们把收到数个ack相同确定序号，此时立即对对应的报文进行补发,叫快重传。
我们之前提到在收到应答之前，报文会保存下来，保存在哪呢
暂时保存在发送缓冲区的滑动窗口中
当收到应答后，通过滑动窗口，删除对应的报文
但没收到应答，滑动窗口一定不会像右滑动

如果是最左侧ACK报文丢了呢？
最左侧丢了，只有最左侧丢了，最后的4001ACK能收到，我们之前的历史报文也能确定接收到

最中间报文丢失
中间报文的丢失，其实就是最左侧的报文丢失，左侧报文没丢，滑动窗口向右滑动，中间的报文变成最左侧报文，此时该中间报文的右边全是收到1001确认序号的ACK，引发快重传。

最右侧报文丢失
最右侧丢失，其实也是最左侧丢失，滑动窗口向右滑动，最右边又变成了最左侧。

快重传VS超时重传
快重传看起来更快，反应更灵敏，为什么又设计了超时重传？
快重传看起来很快很灵敏，但其实它需要收到3个相同的确认序号的ACK才能触发，而可能只收到2个相同的确认序号ACK,就无法触发了，而超时重传解决了这个问题一，他们两其实是互补的丢包解决方案