网络学习--TCP协议、UDP协议

TCP协议

我们上一篇博文说http是基于tcp/ip协议的，我们在面试中也会问到很多关于TCP协议的东西，为什么是上次，不是四次？什么是慢开始？谈谈RSA算法，对称加密和非对称加密的区别，登陆密码用什么加密，高并发下服务器会不会出现问题？总结一下四次挥手？我们这次博文就要解决这些问题。我们了解到长连接对服务器要求很高，服务器要与很多用户建立连接，这样对服务器的要求、性能都提出了很高的要求。

TCP的特性

1. 面向连接、可靠的字节流服务
2. 广播和多播不能用于TCP
3. 使用校验和确认重传机制保证可靠传输
4. 使用滑动窗口来实现流量控制，通过动态改变川口大小进行拥塞控制

它提供的是一种重传机制，故也不是100%可靠协议

三次握手

SYN是位码，表示建立联机，ACK是确认
服务器端在发出syn和ack之后，收到客户端syn和ack之前，这个时候服务器处于SYN-RCVD状态，当收到客户端的ACK之后，才能转入ESTABLISHED状态。
SYN攻击是在短时间伪造大量不存在的ip地址，向服务器不断发送SYN包，服务器返回ack包，但由于ip地址是不存在的，故服务器会源源不断的发送SYN和ACK包。正常的SYN请求被丢弃，导致目标系统运行缓慢，严重影响网络堵塞。
它是一种典型的dos攻击
只要在服务器端发现大量半连接状态的包时，就可以认定是攻击了。netstats可以检测。
解决方案：缩短超时时间、增加最大半连接过滤网关防护、syn cookie技术

四次挥手

中断连接端可以是client端，也可以是服务器。假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，“告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，“就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

接下来我们可以回答上面提出的问题，为什么握手需要三次，挥手需要三次。在握手的时候，客户端发出syn连接请求，服务器端可以发出同步的syn请求以及ack应答报文。但是在挥手的时候，服务器端不能立马关掉服务器，它有可能还有数据传送，所以只能告诉客户端我收到你的关闭请求了。

为什么time_wait还要经过2msl才能返回CLOSED状态
虽然按道理，四个报文都发送完毕，我们可以直接进入closed状态，但是我们必须假想网络不可靠。有啃呢个最后一个ack丢失，就用来重发可能丢失的ack报文。

TCP KeepAlive

TCP KeepAlive 的基本原理是，隔一段时间给连接对端发送一个探测包，如果收到对方回应的 ACK，则认为连接还是存活的，在超过一定重试次数之后还是没有收到对方的回应，则丢弃该 TCP 连接。

UDP

UDP是一个简单的传输协议

1. UDP缺乏可靠性，不保证按顺序到达，也不保证能到达，也不保证重传
2. UDP数据报含有长度，日过一个数据正确的到达目的地，那么该数据包的长度将随数据一起传递给接收方
3. 无连接
4. 支持广播和多播