传输层
端口号（linux内核下是16位）
端口标识应用层中不同的应用程序,例如0-1023应用于知名协议，HTTP-80
进程与端口号的关系：一对多，一对一
＇＇
指令：
pidof :得到进程的pid， pidof 进程 | xargs（从管道得到pid，放在命令行后面）
netstat ：
语法 -选项 ：-l 处于监听状态 -n 协议数字化显示 -t tcp -p 进程信息 -u udp
UDP协议
报头：固定8字节，用于定制数据的大小。本质是一个结构化数据对象。操作：先进行开空间，将结构体和有效载荷结合，然后强转成结构体，填入数据，传字符串数据到别的os上，然后进行强转为结构体数据，就可以拿到报头的信息了。
源端口：发送数据报的应用程序所使用的端口。
目的端口号：匹配上层的应用的端口号，用于交付给上层的应用，进行分用。
UDP长度：整个UDP长度（报头和数据），最大64KB，超过了需要进行打包分开发。
校验值：检验数据再传输过程中是否损坏
基于UDP协议的应用层协议：NFS TFTP DHCP BOOTP DNS
特点：
无连接：知道对方的ip和端口号，可以直接传输
不可靠：没有确认机制，没有重传机制，不用管数据是否发给对方，发了之后就不管了
面向数据报：直接能读完一个完整的数据报，·不用考虑读不完一个数据报。
缓冲区：接收接口要经过接收缓冲区，只有接收缓冲区，因为，可以实现类似于消费者和生产者模型，让进程执行其它任务，而因为不需要可靠性，所以发送直接调用接口经过网络直达对方接收缓冲区
TCP协议
两种工作模式 c->s：
一端发送一条，一端应答一条
一端并发发送多条，一端并发回复多条
报头
不加选项标准20个字节的大小，结构化数据
源端口：发送数据报的应用程序所使用的端口。
目的端口号：匹配上层的应用的端口号，用于交付给上层的应用，bind就是添加到哈希表中，通过haxi的方式找到进程的PCB,进行分用。
4位首部长度：加上选项的报头长度[0,15],报头总长度=首部长度*4字节
序号：标识发出数据的顺序序号，类似于数组下标。
确认序号：用于应答的报文中，对应发来的报文的序号，让对方下一次开始的序号是多少，
对发来的报文序号+1。
小点：两个序号存在的条件是因为，两端都有发送和接收所以要有自己的标识序号
窗口大小：告诉对方自己接收缓冲区剩余大小，对方可以根据这个进行流量控制。
标志位（1/0控制）【标识报文的类型】
URG：tcp的数据是按序到达，如果有数据的紧急指针标志位1，有效载荷中包含了需要被特殊尽快的数据（用16位紧急指针作为偏移量去有效载荷找这块数据，这个数据是一个字节），就可以进行插队，优先处理，用于发带外数据。将紧急数据跳过接收缓冲区队列，直接提交给上层应用进程处理，而普通数据仍按正常流程缓存或处理。
ACK：确认收到1，用于这个报文是否为确认的报文
PSH：定期催促接收方上层取走接收缓冲区的资源1,让read和write的读取条件满足
RST：复位标志位1，单方面认为连接不存在时，用这个标志位告诉对方，进行连接重置，通常用于连接建立后，某一端出问题断开了连接，然后另一端一直发报文。
SYN：建立连接1
FIN：断开连接 1
特点
1.全双工，一个接收区，一个发送区
2.可靠性传输：发消息之后，对方对收到正确的旧消息有应答
3.字节流
4.面向连接
超时重传机制（TCP策略，超时（根据网络情况决定的））
作用：用于处理丢包问题（数据丢了，应答丢了），设置一定时间，如果超过一定时间没有收到对方应答就会重传数据，而这个数据会保存在发送缓冲区里一段时间，之后会被新数据覆盖。如果接收方收到重复的数据，tcp会根据序号自动丢弃收到的重复的数据。
超时时间：根据网络的质量进行浮动变化的。一般以500ms为单位，时间是它的整数倍。
连接管理机制
一次握手的缺点：多个客户端发起建立连接，就会单方面对服务端形成洪水攻击，而客户端没有资源损失，服务器缺一直有连接请求，消耗它的资源。
两次握手的缺点：跟一次握手一样，因为服务端的连接建立成功的回复会丢失，然后客户端还是会洪水般的发起请求，因为他不知道连接建立成功没有。
三次握手是建立连接机制，不保证三次握手成功.（握手期间可能会出现SYN的消息丢失）
三次握手优点：
1.用最小成本验证全双工通信时通常的。验证方法：全双工的功能是能发能收，两次握手能够知道客户端能发能收，服务端则只知道能收，能发需通过要第三次握手的客户端应答证明。
2。可以有效防止单机进行对服务器进行攻击。防御的核心思路是：减少服务器在握手完成前需要消耗的资源，或者更早地识别并丢弃恶意SYN包。
三次握手的目的：
第一次：请求连接，发送带有syn标志位的报头。
第二次：同意连接，采用带有syn和ack的报头回复，此时请求方先建立成功。
第三次 ：收到请求方连接建立成功的ack应答报头，这时接收方再建立成功连接。
这三次握手：实现了以最少次数使双方都完成连接，间接保证了可靠性，因为报文内部有一些数据，两端根据握手的报文内部数据，进行用户数据的传递，建立器连接结构体。
四次挥手
第一次挥手：客户端发送单方面FIN(断开连接），之后不给服务端发用户数据了，但是还有底层报文数据。
第二次挥手：服务端对客户端单反面断连应答
第三次挥手：服务端对客户端也进行单方面断连
第四次挥手：客户端对服务端单方面断联进行应答，这是底层报文数据，不属于用户数据。
四次挥手两端的状态：
1.断开连接是双方都能发起
2.第一个发送断连的状态是FIN_WAIT_1，而回复端进入CLOSE_WAIT
3.第二个发送断连的进入LAST_ACK，而回复端为TIME_WAIT
4.服务端调用close关闭文件描述符后，会发出FIN给客户端，客户端就会发ACK进行应答，如果服务端没有收到客户端的ACK回复，它就不会断开，会进行补发FIN，因此客户端会处于一段时间（2*MSL)的TIME_WAIT。
TIME_WAIT（2倍MSL：两次收发所花的时间，报文生成时间) :是为了防止最后一次服务器没收到ACK，为了让对方去补发FIN，所以会等待一段时间，保证ACK被对方收到，防止滞留报文
立即重启服务端
服务崩掉之后，短时间无法重新bind套接字。
cpp
int setsockopt(SOCKET s, int level, int optname, const char FAR *optval, int optlen);流量控制
报头中的窗口大小就是为了流量控制，通过连接发报文时，在报头中携带自己的窗口大小，让对方根据窗口大小，用相应的速度来传递相应大小的数据。
滑动窗口
本质：基于可靠性，为了提高发送效率，可以并发
发送方的发送缓冲区存在滑动窗口，滑动窗口根据接收方接收缓冲区大小而定的。滑动窗口的前方为已经发送的数据并且收到对方应答，而滑动窗口是发给对方了，还没收到应答。
滑动窗口的原理
1.它是按序号进行发送给对方，类似于数组下标。
2.当发给对方后，并且收到应答，begin会向后移动，begin=确认序号。
3.当发给对方后，收到应答，并且应答中包含对方取走缓存区数据后的新的窗口大小时，end会向后移动，end的位置为begin+对方剩余窗口大小。
4.对方每次的应答是接收到数据的序号+1，告诉发送方下一次发的数据序号应该从这个数字开始。
5.如果对方接收到的数据序号不能连接起来，说明中间发送的数据有丢失情况，因此连续收到的数据都会应答相同的序号，这个序号是丢失数据的前一项没有丢失数据下标+1。
6.如果发送端接收到三次次相同序号，这是发送端就会按这个序号开始，进行重发。
7.发送缓存区的数据满了，数据会重开头进行覆盖已经发送并且收到应答的数据，类似于环形结构。
8.如果应答丢失了，不会受到影响，因为下一次应答的序号还是会按照本来的规则进行，不会进行重发。
拥塞控制
背景：虽然有了滑动窗口，主机能够进行发大量数据，不用等待立马应答。但是，这个也引发了一个问题，在一个网络中，所有主机都发出大量数据，此时网络中会有大量数据，如果网络状态不好，就会都阻塞在网络中，这些数据都无法抵达。TCP就会引入慢启动机制，用少量的数据，来判断网络的状态。
定义：拥塞控制就是在大量数据丢弃了，主机停发数据，等网络状态恢复好了，然后主机再进行慢启动机制，重发丢弃的数据，一开始采用指数性增长，达到一个数值（拥塞窗口）后，根据网络状态开始慢慢加数据。
拥塞窗口
恢复网络过程中，采用指数级的慢启动，前期慢，后期快，其中会引入阈值，来规定达到这个阈值后，开始线性方式增长，拥塞窗口根据阈值变化，它会一直发生变化，因为网络波动的原因。
滑动窗口大小=min[拥塞窗口，对方接受能力]
延迟应答：因为有确认序号，所以可以对多个报文一起确认应答，这样可以先收多个数据，再一起应答，这样可以提高效率。
优点：提高了可靠性，以及效率。
延迟应答
收到一条报文后，并不立即应答，而是等待一段时间（<超时重发等待时间），可能等待一会，用户层会拿走缓冲区的数据，这样应答的窗口大小就会变多，在根据最新收到消息的序号进行应答，这样就可以节省应答时间，提高效率，对方就可以多发几条，在延时应答时间内，可以根据容量多发几条消息，增加网络吞吐量，传送效率就变高了。其中需要与确认应答机制结合，因为确认应答是对已经收到的所有进行应答，所以应答不用每条都进行应答。
捎带应答
定义：发出的数据携带应答的报头就是捎带应答
作用：当两端互发消息时，就可以进行捎带应带，节省单独应答的发送，提高效率，进行互相传递信息。
面向字节流
字节流与数据报的区别：
-
面向字节流（TCP） ：像用水管传输水，水流连续不断，你无法区分哪滴水是哪个杯子倒进去的。
-
面向数据报（UDP） ：像用快递寄包裹，每个包裹独立打包，贴上地址，彼此之间毫无关联。
| 维度 | 面向字节流 | 面向数据报 |
|---|---|---|
| 数据组织 | 连续字节流，无边界。 | 独立数据包，有明确边界。 |
| 传输控制 | 可靠、有序、流量控制。 | 不可靠、无序、无流量控制。 |
| 适用场景 | 大数据量、高可靠性需求。 | 低延迟、容忍丢包、简单请求-响应。 |
| 协议代表 | TCP、SCTP（支持多流）。 | UDP、ICMP。 |
因此：TCP需要在应用层自己决定读多少个字节，才能拿到完整的数据，而UDP直接就会接收到完整的报文，分离之后就能拿到有效的数据了。用字节流可以有效的保证数据传递完整性，因为每个数据之间是有联系的，而数据报之间没有联系。
粘包问题
概念：TCP接收到的数据是一个报文一个报文的过来，但是在缓冲区内只是一串连续的字节数据，没有明确的边界，应用层进行读取时，可能会多读少读，这就是粘包问题。
解决方法：
1.采用定长的报头，根据报头去读取这个报文的有效载荷。
2.采用明确的分隔符，在报文与报文之间添加分隔符，按分隔符读取每一个有效载荷。
3.定长报文，就一开始规定每次发的报文只有一种长度，这样每次读取只需要读这个长度的数据。
bool recvpackage(int sock,string &inbuffer,string *text)//inbuffer用于记录
{ //1.读传递过来的数据
char buffer[1024];
while(true)//为了防止没读完数据，重新读
{
ssize_t n=recv(sock,buffer,sizeof(buffer),0);//读传递的数据
if(n>0)//n是读到的长度
{ buffer[n]=0;
inbuffer=buffer;
auto pos=inbuffer.find(SEM);
string text_len_string=inbuffer.substr(0,pos);
int text_len=text_len_string.size();
int all_len=text_len_string.size()+text_len+2*SEM_LEN;//为了知道有没有读取到一个完整的信息的大小
std::cout << "处理前#inbuffer: \n" << inbuffer << std::endl;
if(inbuffer.size()<all_len)//说明读取不完整，需要重新读取
{std::cout << "你输入的消息，没有严格遵守我们的协议，正在等待后续的内容, continue" << std::endl;
continue;
}
*text=inbuffer.substr(0,all_len);//获得完整的内容包括前缀
inbuffer.erase(0,all_len);//删除读完的内容
std::cout << "处理后#inbuffer:\n " << inbuffer << std::endl;
break;
}
else
{
return false;
}
}
//2.根据数据的前缀，分离出具体的信息，如何分离？先找第一个分隔符，截取字符串[0,分割符位置）
//3.传给输出型参数
return true;
}listen第二个参数
全连接队列：已经完成三次握手，但没有在上层，不能进行发消息，需要被拿到上层才能进行发消息，给服务器维护的缓冲区。长度受第二个参数影响。
半连接队列：客户端对于服务端的连接建立了，而服务端还没建立对客户端的连接。
作用：决定服务端可以连接几个客户端（参数+1）（全连接队列），超过的就会进入半连接队列，如果没有尽快进入全连接，就会被断开，而全连接会被accept拿到上层。因此就是上层连接会有很多个，全连接有几个，全连接之后会被拿到上层去，就退出了全连接队列，这是半连接就会进入全连接队列。