传输层协议

UDP(user datagram protocal用户数据报协议)

        16位UDP长度包含UDP报头+UDP数据，UDP包最大为64k，如果校验和出错会直接丢弃。

UDP特点

        无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;

        不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;

        面向数据报: 不能够灵活的控制读写数据的次数和数量。

UDP缓冲区

        UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;

        UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃。

        UDP的socket既能读也能写，属于全双工模式。

TCP(transmission control protocal传输控制协议)

        4位首部长度，单位为4字节，TCP首部长度最大为15*4=60字节；

        16位窗口大小为发送方的接收缓冲区的可用大小；

        16位TCP校验和，发送端填充，CRC校验，接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部, 也包含TCP数据部分；

        16位紧急指针，标识哪部分数据为紧急数据。

标志位

        URG：urgent紧急的，紧急指针是否有效。

        ACK：acknowledgement确认，确认号是否有效。TCP规定除了最初建立连接是SYN包之外，该位必须设置为1。

        PSH：push推，发送方提醒接收方尽快将数据从缓冲区中读走。

        RST：reset重置，对方要求重新连接，携带此标识的称为复位报文段。

        SYN：synchronize同步，请求建立连接，携带此标识的称为同步报文段。

        FIN：finish结束，请求断开连接，携带此标识的称为结束报文段。

三次握手

        三次握手可以保证服务端可以转嫁同等的成本给客户端；

        验证全双工。

四次挥手

        服务器如果存在大量的CLOST_WAIT，是应用层忘记了关闭sodkfd，导致状态不会往下更新。

        主动断开连接的一方，要维持一段时间的TIME_WAIT，等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSE状态，保证历史数据从网络中消散。

        MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的)；

        同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失，那么服务器会再重发一个FIN，这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK)。

setsockopt接口

        set socket options设置套接字选项。

#include <sys/types.h>

#include <sys/socket.h>

int getsockopt(int sockfd, int level, int optname,void *optval, socklen_t *optlen);

int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);

sockfd:listen套接字fd；

level:选项协议层；目前仅支持SOL_SOCKET和IPPROTO_TCP层次;

optname:选项名称，常用的选项SO_REUSEADDR，重用本地地址，协议在断开连接口，会维持一段时间的WAIT_TIME，此时的端口号不会释放也不会被其他套接字绑定，通过设置此选项可以使端口号可以在WAIT_TIME时被其他套接字绑定。

optval:选项值的指针,需要启用数值设为1即可；

optlen:选项值的长度；

返回值:成功返回0，失败返回-1。

TCP特点

        保证可靠性，同时尽可能的提高性能。

序列号

        TCP将每个字节都进行了编号，即为序列号。

确认应答

        TCP报头中有序号和确认序号来进行确认应答。

面向字节流   

        创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区;

        调用write时, 数据会先写入发送缓冲区中;

        如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;

        如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;

        接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;

        然后应用程序可以调用read从接收缓冲区拿数据;

        另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工.

        由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

        写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;

        读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

连接管理

        三次握手建立连接，四次挥手断开连接。

流量控制

        接收端将自己可以接收的缓冲区大小放入TCP首部中的 "窗口大小" 字段, 通过ACK端通知发送端;

        窗口大小字段越大, 说明网络的吞吐量越高;

        接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;

        发送端接受到这个窗口之后, 就会减慢自己的发送速度;

        如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。

        TCP首部中, 有一个16位窗口字段, 存放了窗口大小信息，16位数字最大表示65535字节，实际上TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M 位。

拥塞控制 

        虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。

        因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据，是很有可能引起雪上加霜的。

        TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。

        为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍；

        此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长；

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

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

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

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

        拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。

超时重传

        发送端将数据发给接收端后，一直得不到应答，就会发起超时重传，接收端如果是因为ack丢了重复收到了接收端发来的包会根据序列号进行去重。

        TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算最大超时时间；

        Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍；

        如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传；

        如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增；

        累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接。

滑动窗口

        一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了);

        窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段);

        发送前四个段的时候, 不需要等待任何ACK, 直接发送;

        收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;

        操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

        窗口越大, 则网络的吞吐率就越高。

        如果接收缓冲区的数据越来越多，相应的滑动窗口就会变小直到为0，因此滑动窗口不一定是向右移动，在接收缓冲区的数据快满的时候，窗口不在进行移动逐渐缩小至0。

快重传

        在连续发起多个包给接收端时，如果是某个ack丢了，发送端可以通过后续的ack确认来继续发送，收到的ack应答会根据确认序号把之前的未确认序号也全部按应答处理。

        如果是某个数据包丢失，接收端会一直发送已丢包序号的确认应答，发送端连续收到三个一样的确认应答之后就会进行重发。

延迟应答

        如果接收数据的主机立刻返回ack应答，此时的窗口可能较小，应用层还没来得及取走数据，因此通过延迟应答可以提高传输效率。

        数量限制: 每隔N个包就应答一次;

        时间限制: 超过最大延迟时间就应答一次;

        具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答

        在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "一发一收" 的. 意味着客户端给服务器说了 "How are you", 服务器也会给客户端回一个 "Fine, thank you";

        那么这个时候ACK就可以搭顺风车, 和服务器回应的 "Fine, thank you" 一起回给客户端。

异常情况

        TCP内置了一个保活定时器，会定期询问对方是否还在，如果发现对方不在了会自动断开连接。

粘包问题

        UDP是一个一个完整的包交付应用层，每个包都有有效载荷的长度，不存在粘包问题；

        TCP接收到的所有数据都放在一个缓冲区中，存在粘包问题，由应用层的协议来进行应用层所需要的包与包的分离。