为什么说Tcp是面向字节流的以及（Tcp粘包问题、TCP/UDP对比、listen函数的backlog参数的意义）
为什么说Tcp是面向字节流的：
Tcp通信的本质是创建一个tcp的socket，同时就会对应的创建一个发送缓冲区和接收缓冲区。
- 调用write时, 数据会先写入发送缓冲区中;
- 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出
- 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去
- 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区；然后应用程序可以调用read从接收缓冲区拿数据;
- 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工
- 而其中的缓冲区，因为本质就是数组，而从数组上进行读、写操作，和河流比较像在流中进行数据的读取和写入！
Tcp协议的粘包问题
tcp协议将数据都放到了缓冲区中，而缓冲区中具体有几个报文是不确定的（因为发送的数据可大可小，可能一次报文就能把数据全部发过来，也可能一次只能发送半个 。。。），所以就类似于粘着的样子，对此我们就需要将数据分出来
对此就需解决上述问题，方案：
- 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可在。报文特殊字符（\r\n）。
- 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可。定长报文（确定报文长度）。
- 通过组合的策略解决问题
- 而对于UDP来说就不会有这种问题，因为UDP有明确的数据边界，并且站在应用层来看使用UDP的时候要么收到完整报文，要么不收。
TCP/UDP对比
- TCP适用于需要可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
- UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP还可以用于广播
- 各自有各自的优点，TCP的可靠性是中性词表示着它们适用于不同的场景。
用UDP如何实现可靠传输(经典面试题)
其实就是参考TCP协议实现可靠性的办法
- 超时重传，若隔一段时间后没收到应答，就重发数据
- 序列号，确保数据顺序，以及去除重复的数据
- 确认应答，确认数据确实发送过去
- …
连接其他机器指令：telnet
telnet + ip + port
TCP层面相关实验理解listen的第二个参数backlog
当没有accept，也是能完成三次握手进行连接（表示即使没有accept不会影响）
此时底层tcp会在自己的连接中，维护一个全连接队列，队列中有效节点的个数是有上限的（也就是listen的第二个参数backlog + 1个，超过后就会变成半连接状态）
如下图backlog的情况：
下图是backlog = 6 + 1 当出现第8个连接时就会出现 SYN_RECV状态
这是因为，Linux内核协议栈为一个tcp连接管理使用两个队列:
- 半链接队列（用于保存处于SYN_SENT和SYN_RECV状态的请求）
- 全链接队列（Accept队列）用于保存established状态，但是应用层没有调用accept取走的请求
此处的全连接队列的长度就会受到listen第二个参数backlog的影响，当该队列满后，就无法让后面的连接状态为established（建立），就会形成SYN_RECV（SYN连接请求）状态
该半连接状态并不会持续很久，它会等待一会尝试连接，当有全连接状态退出时，就能变成全连接状态，否则就会消失