网络复习-OSI七层模型
OSI七层模型
开放系统互联(Open Systems Interconncection )
TCP
传输层协议
- 面向连接
- 每一个tcp连接只能是点对点的（一对一）
- 提供可靠交付服务
- 提供全双工服务
- 面向字节流
应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送
当网络通信采用TCP协议时，在真正的读写操作之前，客户端与服务端之间必须建立一个连接，当读写完成之后，双方不再需要这个连接时可以释放这个连接。连接的建立依靠三次握手，而释放需要四次挥手，所以每个连接的建立都是需要资源消耗和时间消耗的
TCP连接的建立过程（三次握手/四次挥手）
三次握手的过程：
第一次握手
客户端向服务端发送连接请求建立报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入
SYN-SENT状态第二次握手
服务端收到请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完便进入
SYN-RECEIVED状态第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入
ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接建立成功
为什么需要三次握手？
存在这样一种情况：client发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间地滞留了，以致延误到达已经释放连接后的server。本来这是一个早已失效的报文段，但server收到此失效的连接请求报文段后，就误以为这是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用三次握手而是两次握手，那么只要server发出确认，新的连接就建立了；由于现在client并没有发出去建立连接的请求，因此不会理睬server的确认请求，也不会向server发送数据。但server却以为新的连接已经建立，并一直等待client发送数据。这样，server的很多资源就白白浪费掉了。采用三次握手的方法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接。
这个问题的本质是信道不可靠，但是通信双方需要就某个问题达成一致，而要解决这个问题，无论你在消息中包含什么信息，三次通信是理论上的最小值，所以三次握手并不是tcp本身的要求，而是为了满足在不可靠的信道上可靠传输信息这一需求所导致的。三次达到了，那后面你想接着握手也好，发数据也好，跟进行可靠信息传输的需求就没关系了，因此如果信道是可靠的，即无论什么时候发出消息对方一定能收到，或者不关心是否要保证对方收到你的消息，那样就能像udp那样直接发送消息就可以了
为什么A(发起关闭的那一端)在TIME-WAIT状态必须等待2MSL的时间？
- 保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送FIN+ACK报文段的确认，B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在发送完ACK报文段后立即释放连接，没有等待2MSL，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段，这样B就无法按照正常步骤进入CLOSED状态
- 防止已失效的连接请求报文段出现在本连接中，A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的报文段都从网络中消失，这样就可以使下一个新的连接中不会出现这样旧的连接请求报文段