上篇博客讲解了应用层协议，本篇接着讲传输层。
一 传输层：负责数据能从发送端到接收端
在TCP/IP协议中用源端口号，源ip,目的端口号，目的ip ，协议号这样一个五元祖来表示一个通信 （用netstat-n查看）
二 端口号：标识了一个主机上进行通信的不同的应用程序
端口号划分：0-1023知名端口号 1024-65535操作系统动态分配的端口号
常见的知名端口号：ssh使用22端口号
ftp使用21端口号
telnet使用23端口号
http使用80端口号
https使用443端口号
三 常用指令
1.netstat 用来查看网络状态
2.pidof【进程名】 通过进程名来查看进程的pid (ps aux |grep 进程名）
3.给定一个端口号来查进程名或pid (netstat -anp |grep 端口号）
思考：
一个进程是否可以绑定多个端口号？
原因：可以：SOCKET进程间通信，绑定端口号是把文件描述符绑定，一个进程可以创建多个文件描述符，因此可以绑定多个 端口号
一个端口号是否可以被多个进程绑定？
原因：通常情况下不可以，一个绑定，另一个再绑定肯定是不可以的。特殊可以。先绑定再fork,子进程把父进程的文件描述符也 拷贝了，因此就可以绑定
四 UDP协议
1.UDP协议格式
2.UDP协议的特点
（1）无连接：知道对端ip和端口号就可以直接进行传输，不需要建立连接
（2）不可靠：没有确认机制，没有重传机制
（3）面向数据报：不能灵活的控制读写数据的的次数和数量
（4）及时通信：也就是访问速度特别快。因为不保证可靠性
五 TCP协议
1.TCP协议格式
2.TCP协议保证可靠性和效率所依赖的机制
（1）连接管理机制(保证可靠性）
a)三次握手：服务器与客户端在发送数据的准备阶段，进行三次交互来建立一个连接，即我们所说的三次握手
第一次握手：客户端向服务器发送一个SYN的包，请求建立连接
第二次握手：服务器收到包向客户端发送ACK的包以确认，同时发送一个SYN包请求建立连接。即SYN+ACK包
第三次握手：当客户端收到SYN+ACK包后，再发送一个ACK包以确认
三次握手完成后，连接已经建立好，即可以进行数据的传送。
b)四次挥手：所谓的四次挥手指的是，当断开一个TCP连接，需要客户端和服务器四次交互来确认连接的断开
注意：三次握手客户端发起的，但是四次挥手可以是客户端和服务器任何一方通过close发起（底下我们当做客户端先发起）
第一次挥手：客户端向服务器发送一个FIN的包，请求断开连接
第二次挥手：服务器收到之后，像客户端回应一个ACK的包确认这个方向上的连接断开
第三次挥手：服务器接着向客户端发送一个FIN的包，请求断开连接
第四次挥手： 客户端收到之后，向服务器回应一个ACK的包。
c)为什么建立连接要三次握手而断开连接确是四次挥手
这是因为服务器端的LISTEN状态下的socket当收到SYN报文的建立连接请求后，可以把ACK和SYN(ACK起应答作用，SYN起同步作用）放在同一个报文里面来发送。但是关闭连接的时候，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了，但是未必你的数据全部发送给对方了，所以你未必会马上关闭，你也许还要发送一些数据给对方后，再发送FIN报文给对方，来表示你同意现在可以关闭连接了。所以关闭的时候ACK报文和FIN报文往往是分开的，因此需要四次挥手。
d)TCP建立连接一定要是三次握手吗？
不是，最少是三次.。
如果是两次握手，客户端首先发送SYN的连接建立请求报文，服务器端回复SYN ACK，报文丢失（因为最新的一次报文是无法确定的），因此客户端收不到回复报文，认为连接请求失败，而服务器则认为连接已经建立完成，并为此次连接管理和维护耗费资源。如果大量的客户端都发生这种情况，那么在服务器端就有大量的闲置连接需要管理和维护，一直占用资源，导致服务器的负载太重，最终挂掉。（大量的恶意连接，会对服务器进行”洪水攻击”）。同样四次握手也不可以。偶数次握手都不可以。
如果是三次握手，客户端认为连接建立好了，而服务器认为连接没有建立好，会给客户端发送RST让客户端重新建立连接。会在客户端维护大量连接，对服务器没有影响。
e)为什么最先断开连接的一方要进入TIME_WAIT，等待2MSL的时间？（1MSL为一个报文从A端到B端花费的最大时间）
保证最后一个ACK丢包，还有机会重传。但是时间又不能太长（因为连接耗资源）。
f)TIME_WAIT一定会存在，但是我们可以重用TIMEWAIT绑定的端口号,j解决因为TIME_WAIT状态引起的bind失败.
在socket代码的socket()和bind()之前插入如下代码
int opt=1;
setsockopt(listenfd, SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
(2)确认应答机制 （保证可靠性）
不是说我发的你一定可以收到，而是指你收没收到我可以感应的到
TCP将每个字节的数据都进行了编码，即为TCP报头中的***，每个ACK都带有对应的确认序号，告诉发送者我收到了哪些序号，下次你从哪里发。
（3）超时重传机制（保证可靠性）
主机A在一定时间内没有收到，主机B的确认应答，会进行重传。原因：1.数据包丢了，2.应答丢了
（4）滑动窗口（保证效率）----以前的发送方式，很多时间都是在等待ACK
窗口大小：无需等待确认应答，而可以连续发送数据的最大值
滑动窗口是信息发出去，但是还没有应答，收到一个应答，往后移动。
a）思考：窗口越大，吞吐量越大。但是越大越好吗？
答案：否要考虑到接受缓冲区的接受能力，还有网络状况
b)如果出现了丢包，如何进行重传。
1.数据包抵达，ACK丢了。（丢了不要紧，可以根据后面的应答确认）
2.数据包丢了，快重传
（3）流量控制（保证可靠性）
接收端处理数据的速度是有限 的，如果发送端发的太快，导致接收端的缓冲区被打满，如果继续发送，就会导致丢包重传，丢包重传等的一连锁的反应。因此应该根据接收端的处理能力，来决定发送端的发送速度，这叫做流量控制
（4）拥塞控制（提高效率）
（5）捎带应答（提高效率）
（6）延迟应答（提高效率）