在网络层，IP首部中有一个协议字段，用来标识网络层的上一层所采用的是哪种传输层协议，根据这个字段的协议号，就可以识别IP传输的数据是TCP或者UDP的内容
在传输层，TCP和UDP为了识别自己所传输的数据应该发给哪个应用，设定了端口号
传输协议TCP和UDP通过接受的数据中的目标端口号识别目标应用程序
工作机制？
服务端的程序要提前启动，准备接受客户端的请求。在Linux系统中，服务端的程序叫做守护线程，例如HTTP--httpd，SSH--sshd，但是不需要将这些守护进程一一启动，而是启动一个可以代表这些守护进程接收数据的一个超级守护线程，该超级守护线程接收到客户端的请求之后，会创建fork一个新的进程并转换exec为一个对应的守护线程。
MAC地址，识别同一数据链路中的不同计算机
IP地址，识别TCP/IP网络中互联的主机和路由器
端口号：识别同一计算机中的不同应用程序。端口号可以采用标准既定的，也可以由操作系统动态分配互不冲突的。端口号是由其使用的传输层协议决定的，因此，不同的协议可以使用相同的端口号。
不同的通信？
只要源IP地址、目标IP地址、协议号、源端口号、目标端口号中有一个不一样，就是不一样的通信
TCP
面向连接的（确认通信对端存在时，才会）、可靠的流协议（流协议的意思：TCP发送数据时，虽然是一段一段发，可以保证顺序，但是可以看成是没有间隔的数据流）
可靠：顺序控制、重传机制、检验和、序列号、确认应答、连接管理、窗口控制
网络利用率：拥塞机制、流量控制
1.利用序列号和确认应答提高可靠性
应答处理：当发送端的数据到达接收端之后，接收端的主机会返回一个“已收到”的消息通知（确认应答）ACK（Acknowledgement）
重发机制：发送端发送数据之后，会等到接收端的确认应答，如果收到了，表明数据已经成功到达对端；如果没有收到，可能丢失了（发送的数据包丢失了或者是接收端返回的ACK丢失了）或者由于网络原因延迟了。发送端在发送数据一段时间之后，没有收到ACK，就认为上一个数据包丢失了，重发
重复控制：重发如果是因为接收端的ACK丢失了或者由于某些原因延迟，而导致发送端重新发送数据包，就会导致接收端接收到重复的数据，虽然接收端可以将重复的包丢弃，但是，这加重了主机的负担。序列号。序列号按照顺序给发送数据的每一个字节标上编号，接收端接收数据之后，查询TCP首部的序列号和数据长度，将自己下一步要接收端的序号作为确认应答返回回去。
2.重发超时的确定？
重发超时，是在重新发送数据之前，等待确认到达的那个特定的时间间隔
这个时间间隔和网络环境有很大关系
每次发送包的时候，都计算时间以及偏差，重发超时的时间比 数据发送时间+偏差 的和大一点
数据重发之后，还是收不到ACK，又要进行重发，此时，等待确认应答的时间将以2倍、4倍指数级增长
数据也不是一直一直重发，当重发一定次数之后，仍然收不到应答，就会认为网络或者对端主机异常，强制关闭连接
3.连接管理
TCP是面向有连接的，在发送数据之前，先确定通信两端存在，做好通信两端的准备工作；在数据发送完毕之后，要及时关闭连接
（1）三次握手
第一次握手:建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)（请求建立连接时，SYN=1，服务端由SYN=1得知，客户端是想建立连接）
第二次握手:服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态
第三次握手:客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED(TCP连接成功)状态，完成三次握手
为什么三次握手？
三次握手主要是防止已经过期的连接再次传到被连接的主机上
客户端发送连接请求，由于某些原因，请求未到达服务器（但是并没有丢失），此时，客户端重新发送请求，建立了连接，正常收发数据之后，关闭了连接。这时，刚才未到达的连接请求到达了服务器，如果是三次握手，服务器在收到这个请求之后，会发送ACK+SYN，等待客户端的确认，此时，由于客户端已经正常退出了，服务端在一段时间之后收不到ACK会强制断开。。。但是，如果是两次握手，服务器在收到那个过期请求之后，再发送ACK即可建立连接，但是此时客户端已经退出了，这个连接是不存在的，服务端还会在此处等待客户端发送数据，造成资源浪费。
（2）四次挥手
第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段(FIN表示英文finish)。主机A进入FIN_WAIT_1状态
第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序:对方要求关闭连接(先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段)。主机B进入CLOSE_WAIT状态；主机A收到ACK之后，进入FIN_WAIT_2状态
第三步，主机B的应用程序告诉TCP:我要彻底的关闭连接，TCP向主机A送一个FIN报文段。主机B进入LAST_ACK状态。
第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。主机A进入TIME_WAIT状态，在该状态下，主机A等待2MSL之后（等待2MSL是为了保证ACK发送成功），没有收到服务器的回复，表示服务器已经正常关闭了，自己进入CLOSED状态。主机B收到ACK之后，进入CLOSED状态
为什么四次挥手？
比如客户端发送关闭连接的请求，服务端在收到这个请求之后，发现自己还没准备好关闭连接，但又怕客户端超时重发，因此，先给客户端返回一个ACK，告诉客户端，已经收到了关闭连接的请求。待服务端准备好关闭连接之后，再向客户端发送关闭连接的请求
4.以段为单位发送数据
在建立TCP连接时，确定发送数据包的单位，最大消息长度（Maximum Segment Size） MSS
MSS的理想状态是，IP中不会被分片处理的最大数据长度
TCP在传递大量数据时，将数据以MSS大小分割，进行发送
MSS是在通过三次握手建立连接的时候确定的，在三次握手的过程中，两端的主机会在TCP首部写入自己的接口能够适合的MSS，然后选择较小的那个
5.利用窗口机制提高效率
如果一次发送一个MSS大小的数据，然后等待对方ACK，如果包的往返时间很长，通信的性能就会很低，网络吞吐量降低
利用窗口机制，确认应答不再针对每一个分段，而是针对一个窗口。窗口的大小是根据接收端主机的实际接收数据的能力确定的 。
窗口大小：发送数据时，无需等待应答，可以继续发送数据的的最大值，多个段同时应答
丢失的数据如何重传？
利用窗口机制，在窗后之内的数据段，即使没有收到确认应答，也可以发送，但是，存在窗口中的数据丢失的情况，发送端设置缓存区保存待被重传的数据，直到收到相应的应答，将它们从缓存区清除
收到确认应答之后，窗口滑动到确认应答中指定的序列号
6.窗口控制与重发机制
（1）确认应答丢失
在没使用窗口机制时，应答丢失，也需要重发，然后在接收端将重复数据丢弃；使用了窗口机制之后，即使发送端没有收到某些确认应答，也不需要重发
（2）段丢失
使用了窗口机制之后，如果中间的某一个段丢失，收到的确认应答就一直会是丢失的这个报文段的序号，当发送端三次以上收到同样的确认应答，就认为该数据段丢失，重发
7.流控制（流量控制）
有一种情况，接收端正在处理其他事情，导致其无法接收任何数据，此时，发送端发送的数据会被直接丢弃，发送端等待不到接收端的ACK，会重发，陷入死循环，浪费网络流量，因此，发送端需要根据接收端的实际情况发送数据。这就是流量控制。
接收端主机向发送端主机通知自己可以接收数据的大小，发送端发送不超过该值的数据（窗口大小）。TCP首部有一个专门通知窗口大小的字段。
8.拥塞机制
利用窗口机制，不再以一个数据段为单位发送确认应答，在收不到确认应答的情况下，可以连续发送一个窗口大小的数据，窗口的大小写在TCP头部，由接收端的实际处理能力决定。
在通信刚开始的时候，不宜发送大量数据，先通过一个慢启动算法得出数值。
UDP
面向无连接的、不可靠的、高速的、实时性高的
User Datagram Protocol
将应用程序发送的数据在收到的那一刻，立即原样发送到网络层
传输途中，即使丢包，也不重发
包达到时，即使乱序，也不纠正
将细节控制交给应用程序
用于：即时通信（视频、音频）、包总量较少的通信（DNS、SNMP）、广播、多播