网络基础（三）—— 传输层

传输层

1、端口号用来标识特定主机上的唯一一个网络服务进程。
2、IP+端口号=套接字（标识了互联网上唯一一个进程）
3、在TCP/IP协议中，用源IP，源端口号，目的IP，目的端口号，协议号这样一个五元组来标识一个通信（链接）。可通过netstat -n查看

常见端口号：

• 22：ssh服务器端口（安全登录、文件传送(SCP)和端口重定向）
• 21：ftp服务器端口（文件传输协议）
• 23：telnet服务器端口（不安全的文本传送）
• 80：http服务器端口
• 443：https服务器端口
• 3306：MySQL数据库端口号
• 8080：Tomcat端口号
  cat /etc/services查看知名端口号

一个进程可以绑定多个端口号，但是一个端口号不可以被多个进程绑定。

netstat

netstat是一个用来查看网络状态的重要工具。
（iostat在Linux下查看IO信息）

常用选项：

• n：拒绝显示别名，能显示数字的全部转化为数字
• l：仅列出有在监听的服务状态（只有TCP会监听）
• p：显示建立相关链接的程序名
• t：仅显示TCP相关选项
• u：仅显示UDP相关选项
• a：显示所有选项，默认不显示LISTEN相关

补充：
ps：查看网络进程
ping：查看网络是否连通
ifconfig：用于配置和显示Linux内核中网络接口的网络参数
（ifconfig作用：配置本地回环地址，配置网卡的IP地址，激活网络适配器）
ps aux | grep tcpserver 查看自己正在用的网络服务

pidof

pidof用来查看服务器的进程id。
语法：pidof [进程名]

UDP 协议

UDP协议端格式：

将报头与有效载荷分离的方式：
1、特殊符号
2、定长报头（UDP8位）

UDP特点：

• 无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接。
• 不可靠：没有确认重传机制，如果因为网络故障该段无法发送到对方，UDP协议层也不会给应用层返回任何错误信息。
• 面向数据报：不能灵活的控制读写数据的次数和数量。应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。

优点：简单，高效。
注意：
1、UDP没有真正的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层再进行传输。UDP具有接收缓冲区，但是并不能保证接收到的UDP报的顺序和发送的UDP报顺序一致，如果缓冲区满了，再到达的UDP数据就会被丢弃。
2、UDP协议首部的16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度。也就是说，一个UDP能传输的数据最大长度是64K(包含UDP首部)。如果需要传输的数据超过64K，就需要在应用层手动分包，多次发送，并在接收端手动拼装。

基于UDP的应用层协议：

• NFS：网络文件系统
• TFTP：简单文件传输协议
• DHCP：动态主机配置协议
• BOOTP：启动协议（用于无盘设备启动）
• DNS：域名解析协议
• 还有自己写UDP程序时自定义的应用层协议
  局域网使用UDP协议

TCP协议

TCP：传输控制协议，要对数据的传输进行一个详细的控制。

TCP保证可靠性的条件：
1）校验和
2）序列号（按序到达+去重）
3）确认应答
4）超时重传
5）面向链接
6）流量控制
7）拥塞控制
TCP提高性能：
1）滑动窗口
2）快速重传
3）延迟应答
4）捎带应答

TCP协议段格式

• 4位TCP报头长度：表示TCP头部有多少个32位bit。TCP头部最大长度是15*4=60
• 6位标志位：
  • URG：紧急指针是否有效
  • ACK：确认号是否有效
  • PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
  • RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段
  • SYN：请求建立连接，我们把携带SYN标识的称为同步报文段
  • FIN：通知对方本端要关闭了，我们把携带FIN标识是称为结束报文段
    SYN和FIN要么一个被置1，要么都不设置。

序号和确认序号是为了保证通信双方的可靠性。
序号的作用：
1）保证数据按序到达
2）明确告诉发送方哪些数据丢失
3）去重

三次握手

三次握手就是客户端首先发送一个同步报文段(SYN)给服务器，请求建立链接，服务器收到后，返回一个确认ACK给客户端，并且也发送自己的SYN给客户端，客户端发送一个针对服务器发来的SYN的确认应答ACK给服务器，至此三次握手完毕。

1、为什么不是两次握手？
链接的建立需要成本，链接一旦建立，客户端和服务器都需要花内存去维护链接，成本主要体现在内存和时间上。如果是两次握手，客户端发起请求，服务器给出响应，最后一个包丢失的时候，服务器端认为链接已经建立好了，而客户端认为链接没有建立好，所以客户端会继续发送请求，如果这是一个恶意客户端，它向服务器发送了大量SYN，服务器就会有大量的闲置链接，设计存在缺陷。
2、为什么不是四次握手？
三次握手可以满足要求，为什么还要进行第四次握手呢，就相当于参加三次高考，第三次成功考上大学，第四次就一定会被录取吗，也会存在第四次高考失利的情况，所以这第四次是根本没有必要的。
三次握手前两次握手丢失了我们并不怕，因为双方都认为三次握手没有成功，都不会为了维护链接而开辟资源，只有第三次比较重要，因为最后一个报文是客户端发送的，即使丢失，客户端认为链接建立好了，服务器端认为没有建立好，最后一个报文丢失是客户端的损失，但是这并没有什么影响。同理，四次握手前三次握手丢失了我们也不怕，因为链接并没有建立成功，只有第四次丢失会有影响，但是这又把锅甩给服务器了。
三次握手最后一次报文丢失，客户端认为链接建立好了，所以开始发送数据，而服务器端认为链接没有建立好，由于TCP在通信之前应该先建立链接，链接没建立好，但服务器端却收到客户端发来的正常报文，服务器会认为客户端出问题了，所以它会给客户端发送一个确认报文，里面携带一个RST，告诉客户端重置链接，也就是重新建立链接。

四次挥手

四次挥手的过程是双方的事情，必须征得双方同意，客户端主动发起FIN，代表已经同意断开链接，服务器只需要ACK就可以了。接下来服务器也是发送一个FIN，客户端发送一个ACK就可以彻底断开链接。
需要注意的是，客户端给服务器发完ACK后，它认为四次挥手完毕，链接断开，所以有可能ACK还在路上的时候，客户端已经释放资源。如果这时这个ACK丢失了，站在服务器的角度，四次挥手还没有完成，它认为我给你发送了断开链接的请求，你却没有理我，所以服务器会再次发送FIN请求，但是它再也收不到ACK了，因为客户端已经断开链接了，这就可能导致服务器一直维护一个已经断开的链接，不停的询问客户端是否还在，浪费服务器资源。
所以主动断开链接的一方要进入一个TIME_WAIT状态，当客户端发送最后一个ACK之后，理论上四次挥手完毕，可以退出了，但是它并不退出，而是等，如果这个报文丢失了，服务器端会再次发送FIN，这次客户端就可以再次发送ACK了。但是在等的期间，客户端怎么知道这个ACK有没有丢？道理很简单，“没有消息就是最好的消息”，如果在等的期间，没有收到服务器发给我的第二个FIN，就认为ACK对方收到了。反之就说明ACK丢失了，就要重发。
TIME_WAIT机制还有一个作用，有这样一种可能，客户端和服务器正在通信，这时双方说我们不要通信了，要断开链接，但是在网络中还有一些双方之前发出去的数据，这些数据在路由器中卡着，还没有被对方收到，然而要断开链接了，有可能链接都断了数据还停留在网络中，这样发送和接收方都没有拿到完整的数据，所以TIME＿WAIT至少保证在最后一次断开链接期间，客户端和服务器都不会再发送数据了，保证通信双方的消息在网络中消散掉。
TIME＿WAIT时间长度：我们把数据从A端到B端在路上所花的最大时间叫做MSL，从A端到B端，再从B端到A端的时间是2MSL，所以TIME_WAIT时间就是一来一回的时间，即2MSL。
CLOSE_WAIT：如果一方被动的断开链接，那么它需要维持一个CLOSE_WAIT状态，对方要求断开链接，但是有可能我的数据还没有发完，所以可以暂时不调用CLOSE，等所有消息发送完毕再调用CLOSE关闭。

TCP和UDP对比：
1）TCP是一种面向连接、面向字节流、可靠的传输控制协议；UDP是一种无连接、面向报文、不可靠的用户数据报协议。
2）TCP应用于文件传输、重要状态更新等场景；UDP用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等。
3）TCP头部20字节，UDP头部只有8字节。
4）TCP是连接的通信，有三次握手，确认重传等过程，实时性较差，UDP没有建立连接的过程，实时性较强。
5）TCP连接只能点到点，UDP支持一对一，一对多，多对一，多对多的交互通信。