TCP与UDP区别

TCP连接是由4个值来识别的： <源IP地址、源端口号、目的IP地址、目的端口号>

• TCP是面向连接的、可靠的 
  其实网络的不安全不稳定特性，无论多少次握手都不能保证连接的可靠性 
  但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性

• UDP 无连接的、不可靠 
  UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发

如何保证UDP的连接可靠性？

  本人想法，仅供参考：如果不是特别注重UDP的可靠性，像教师发作业这样的场景丢失一两个是完全可以理解的，大不了老师在多发几次，但是肯定有一只收不到的机子。。。当然了，我们如果想要确保UDP的可靠性，我想到的方法是给每个UDP添加一个不同的uid，通过uid来返回是否接收到

NAT穿透技术

NAT（Network Address Translation，网络地址转换）是一种网络地址翻译技术，将内部私有IP地址改变成可以在公网上使用的.

NAT三种实现方式

• 静态地址转换：一个公网IP对应一个内部IP,一对一转换

• 动态地址转换：N个公网IP对应M个内部Ip,不固定的一对一IP转换关系．同一时间，有M-N个主机无法联网．

• 端口多路复用：对外只有一个公网IP,通过端口来区别不同内部IP主机的数据．

网关

• 网关（gateway）能在不同协议间移动数据

• 路由器（router）是在不同网络间移动数据 
  相当于传统所说的IP网关（IP gateway）

三次握手

一些名词

• seq （Sequence Number）序列号，这是为了连接以后传送数据用的
• ack（Acknowledgment Number）确认序列号，是对收到的数据包的确认，值是等待接收的数据包的序列号。
• SYN synchronous 同步信号
• ACK Acknowledgement 应答信号， 当 ACK=1时候表示ack字段有意义
• SYN 和 ACK 也表示 TCP 的标志位?

三次握手的步骤

1. 客户端 发起握手，目的端点是 服务端 的端点 post_server 
   
   • 生成一个随机数作为它的初始化发送序号 x
   • 发出一个同步报文段，SYN=1，发送序号 seq=x
   • 并进入SYN_SEND状态，等待服务器确认
2. 服务端监听到端口 post_server 上有连接请求，响应 
   
   • 生成一个随机数作为它的初始发送序号 seq = y
   • 发出同步报文字段并对主机 A 端口1的连接请求进行确认，发送ack=x+1
   • 即发送 SYN+ACK 包，此时服务器进入SYN_RECV状态
3. 主机 A 
   
   • 发出对 服务端 端口 post_server 的确认，确认序号 ack=y+1，还有seq=x+1
   • 客户端和服务器进入ESTABLISHED状态，完成三次握手

为什么采用3次握手而不是2次握手?

• 第一次握手 客户端发，服务端 知道 客户端 可以 发消息
• 第二次握手 服务端收和发，客户端 知道 服务端 可以 接收消息 和 发消息
• 第三次握手 客户端收和发，服务端 知道 客户端可以 接收消息 和 发消息

3 次是双向通信的最小值，也就是 SYN, SYN ACK, ACK ，两个发送、两个接收 ，其中第二次把接收和发送合在一起了

如果两次握手的话，客户端有可能因为网络阻塞等原因会发送多个请求报文，这时服务器就会建立连接，浪费掉许多服务器的资源。所以要增加第三次握手。

第3次失败会怎么办?

第三次失败，只有客户端处于成功状态（因为第2次服务器返回了ACK），服务器端没有接收到客户端的 ACK。

这要分几种情况讨论：

• In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine.
  也就是说客户端发出的 ACK 丢失了，发出的 下一个数据包 没有丢失，则服务端接收到下一个数据包（这个数据包里也会带上 ACK 信息），能够进入正常的 ESTABLISHED 状态

• 如果服务端和客户端都没有数据发送，或者服务端想发送数据（但是发不了，因为没有收到客户端的 ACK），服务器都会有定时器发送第二步SYN+ACK数据包，如果客户端再次发送ACK成功，建立连接。

  如果一直不成功，服务器肯定会有超时设置，超时之后会给客户端发RTS报文，进入CLOSED状态，防止SYN洪泛攻击。

四次握手关闭连接

1. 主机 A 关闭 A主机的 端口1 到 B主机的 端口2 的传输连接：

   • 应用程序通知 TCP 数据已经发送完毕时，关闭连接
   • TCP 向主机 B 发送一个带 FIN 附加标记的报文段（FIN 表示 finish），FIN=1，seq=x

2. 主机 B 响应： 
   

   • 收到这个 FIN 报文段之后，并不立刻用 FIN 报文段回复主机 A，而是先向主机 A 发送一个确认序号 ，ACK=1，ack=x+1
   • 同时通知自己相应的应用程序，主机 A 方传输已经结束，对方要求关闭连接（先发送 ACK 的目的是为了防止这段时间内，主机 A 重传 FIN 报文段） 
     

   此时 A 到 B 方向上的传输连接已经关闭（看第4有TIME_WAIT状态等待2MSL，第2步的 A 到 B 并没有彻底关闭？），但是主机 B 到 A 还可以发送数据，连接处于半关闭的状态。（因为原来 TCP 是全双工的工作方式，只关闭了一端的连接）

3. 主机 B 关闭 端口2到端口1的传输连接：

   • 应用程序告诉 TCP: 我要彻底地关闭连接
   • TCP 收到对最后数据的确认后，向主机 A 发送一个 FIN 报文段。FIN=1，seq=y，y 是 B 发送数据的最后字节的序号加1。ACK=1，seq=x+1。

4. 主机 A 响应：

   • 收到这个 FIN 报文段之后，向主机 B 发送一个 ACK 表示连接彻底释放。ACK=1，ack=y+1
   • 主机B收到主机A的ACK报文段以后，就关闭连接；此时，主机A等待2MSL （Maximum Segment Lifetime）后依然没有收到回复，则证明主机 B已正常关闭，那好，主机A也可以关闭连接了。

为什么连接的时候是三次握手，关闭的时候却是四次握手?

TCP是全双工模式，关闭连接时，当 主机 B收到主机A的FIN报文时，仅仅表示主机 A不再发送数据了但是还能接收数据。

主机 B也未必全部数据都发送给A了，所以B可以立即close；也可以发送一些数据给A后，再发送FIN报文给对方来表示同意现在关闭连接，因此， 主机 BACK和FIN一般都会分开发送。