定义了网络框架,以层为单位实现协议,同时控制权逐层传递。
OSI实际并没有落地,TCP/IP 5层协议栈是目前主流的落地实现。
TCP/IP协议栈不止是传输层tcp/网络层ip, 还包括应用层等,这是一个协议簇,只是因为TCP/IP很具代表性。
不管是OSI还是TCP/IP5层协议栈,均会出现应用程序和操作系统边界(代码执行在用户态/内核态)。
边界调用被称为系统调用system call, socket api
便是TCP/IP协议栈中应用层的网络编程接口。
TCP: Transmission Control Protocol
是面向连接的,可靠的,基于字节的、双向流式
传输层协议。
UDP: USer Datagram Protocol
面向消息的传输服务,传输的数据是有边界的。
区别:
TCP可靠性是tcp三次握手的基础,在此之上,增加了seq、ack数据确认机制、 拥塞控制, 其中ack= seq+len(data)。
UDP: 想法就发,不用三次握手建立连接。
我们目前常见的应用场景底层都是tcp,比如http请求、sql数据库请求。
建立TCP连接之后,才能做http请求、sql请求,tcp连接很耗时,故服务器都存在连接池化机制。
这里我要给自己强调的是:开发者对于tcp一定不要带入
http请求-响应模型
,tcp是双向通信流。
TCP粘包并不是TCP协议造成的问题,因为tcp协议本就规定流式传输(由算法决定,固定缓冲区、拥塞控制、大小包合并),它不含消息、数据包等概念,需要应用层自己设计消息边界。
粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。
数据链路层,网络层的粘包和拆包问题都由协议自行处理了,我们日常的网络应用开发都在对接传输层,故面临的粘包问题指的是TCP粘包。
HTTP 超文本传输协议的规定如下:
附录: ip报头结构:[源ip、目标ip在这定义]
梳理了整个TCP/IP协议栈的流程,结合TCP报头/IP报头, 我们就知道粘包、拆包一直都存在,只是拆到TCP层的时候,我们没有办法区分应用层断续发送的请求/调用, 这就是我们口口相传的TCP粘包/拆包问题, 需要应用层用特殊分隔符或者长度解析。