https://www.cnblogs.com/neowu/p/10744786.html
开放式系统互联通信参考模型(Open System Interconnection Reference Model,缩写为 OSI),简称为OSI模型(OSI model),一种概念模型,由国际标准化组织提出,一个试图使各种计算机在世界范围内互连为网络的标准框架。定义于ISO/IEC 7498-1。
OSI七层网络模型(从下往上):
第1层 物理层
物理层(Physical Layer)在局部局域网上传送数据帧(data frame),它负责管理计算机通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机接口卡等。
第2层 数据链路层
数据链路层(Data Link Layer)负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时,会形成帧。数据链表头(DLH)是包含了物理地址和错误侦测及改错的方法。数据链表尾(DLT)是一串指示数据包末端的字符串。例如以太网、无线局域网(Wi-Fi)和通用分组无线服务(GPRS)等。
分为两个子层:逻辑链路控制(logical link control,LLC)子层和介质访问控制(media access control,MAC)子层。
第3层 网络层
网络层(Network Layer)决定数据的路径选择和转寄,将网络表头(NH)加至数据包,以形成分组。网络表头包含了网络数据。例如:互联网协议(IP)等。
第4层 传输层
传输层(Transport Layer)把传输表头(TH)加至数据以形成数据报。传输表头包含了所使用的协议等发送信息。例如:传输控制协议(TCP)等。
第5层 会话层
会话层(Session Layer)负责在数据传输中设置和维护计算机网络中两台计算机之间的通信连接。
第6层 表达层
表达层(Presentation Layer)把数据转换为能与接收者的系统格式兼容并适合传输的格式。
第7层 应用层
应用层(Application Layer)提供为应用软件而设的接口,以设置与另一应用软件之间的通信。例如: HTTP,HTTPS,FTP,TELNET,SSH,SMTP,POP3.HTML.等。
TCP/IP四层模型
TCP/IP是一组协议的代名词,它还包括许多协议,组成了TCP/IP协议簇。 TCP/IP协议簇分为四层,IP位于协议簇的第二层(对应OSI的第三层),TCP位于协议簇的第三层 (对应OSI的第四层)。TCP/IP通讯协议采用了4层的层级结构,每一层都呼叫它的下一层所提供 的网络来完成自己的需求。这4层分别为:
应用层:应用程序间沟通的层,如简单电子邮件传输(SMTP)、文件传输协议(FTP)、 网络远程访问协议(Telnet)等。
传输层:在此层中,它提供了节点间的数据传送服务,如传输控制协议(TCP)、 用户数据报协议(UDP)等,TCP和UDP给数据包加入传输数据并把它传输到下一层中, 这一层负责传送数据,并且确定数据已被送达并接收。
网络互连层:负责提供基本的数据封包传送功能,让每一块数据包都能够到达目 的主机(但不检查是否被正确接收),如网际协议(IP)。
主机到网络层:对实际的网络媒体的管理,定义如何使用实际网络 (如Ethernet、Serial Line等)来传送数据。
TCP/UDP区别讲解
1)IP地址
DNS(Domain Name System)域名系统是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式,能够使人更方便地访问互联网。DNS使用TCO和UDP端口53。当前,对于每一级域名长度的限制是63个字符,域名总长度则不能超过253个字符。
为什么要有DNS呢,IP地址(一长串数字)是给计算机使用的,人脑存储的记忆比数据库差太多。举个例子,电话簿,是记名字方便,还是记号码方便,答案显然易见。
当你在电脑输入https://www.google.com/,然后敲回车。电脑会根据你输入的域名解析IP。
1.如果你的电脑配置了Host文件,电脑会优先查询Host文件是否有对应的记录,如果有,直接拿到该记录的IP就结束。
2.如果Hsot文件没有该记录,电脑会看是否设置域名服务器。
2.1如果没有设置的话,浏览器会直接报错,域名无法解析。
2.2如果设置了,电脑会向该域名服务器发送域名查询的请求,等待域名服务器的响应。
2.2.1如果无回应,域名还是无法解析。
2.2.2如果回应了,可以根据根据域名服务器的应答信息,得到该ip地址。
2)端口
1. 用于区分不同的应用程序
2. 端口号的范围为0-65535,其中0-1023未系统的保留端口,我们的程序尽可能别使用这些端口!
3. IP地址和端口号组成了Socket,Socket是网络运行程序间双向通信链路的终结点, 是TCP和UDP的基础!
4. 常用协议使用的端口:HTTP:80,FTP:21,TELNET:23
3)TCP协议与UDP协议的比较:
TCP协议流程详解:
首先TCP/IP是一个协议簇,里面包括很多协议的。UDP只是其中的一个。之所以命名为TCP/IP协议, 因为TCP,IP协议是两个很重要的协议,就用它两命名了。
下面我们来讲解TCP协议和UDP协议的区别:
TCP(Transmission Control Protocol,传输控制协议)是面向连接的协议,即在收发数据钱 ,都需要与对面建立可靠的链接,TCP的三次握手以及TCP的四次挥手!
TCP的6种标志位的分别代表:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码) (ack)
各个状态的意义如下:
LISTEN - 侦听来自远方TCP端口的连接请求;
SYN-SENT -在发送连接请求后等待匹配的连接请求;
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;
ESTABLISHED- 代表一个打开的连接,数据可以传送给用户;
FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
FIN-WAIT-2 - 从远程TCP等待连接中断请求;
CLOSE-WAIT - 等待从本地用户发来的连接中断请求;
CLOSING -等待远程TCP对连接中断的确认;
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认;
CLOSED - 没有任何连接状态;
三次握手: 建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立, 在Socket编程中,这一过程由客户端执行connect来触发,具体流程图如下:
- 第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server, Client进入SYN_SENT状态,等待Server确认。
- 第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位 SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求 ,Server进入SYN_RCVD状态。
- 第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK 置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则 连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以 开始传输数据了。
四次挥手: 终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。 在Socket编程中,这一过程由客户端或服务端任一方执行close来触发,具体流程图如下:
- 第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入 FIN_WAIT_1状态
- 第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同, 一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
- 第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK 状态。
- 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。 另外也可能是同时发起主动关闭的情况:
另外还可能有一个常见的问题就是:为什么建立连接是三次握手,而关闭连接却是四次挥手呢? 答:因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里 发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还 能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些 数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会 分开发送。
UDP协议详解:
UDP(User Datagram Protocol)用户数据报协议,非连接的协议,传输数据之前源端和终端不 建立连接,当它想传送时就简单地去抓取来自应用程序的数据,并尽可能快地把它扔到网络上。 在发送端,UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽 的限制;在接收端,UDP把每个消息段放在队列中,应用程序每次从队列中读一个消息段。 相比TCP就是无需建立链接,结构简单,无法保证正确性,容易丢包。
Http协议
Http(超文本传输协议)是用于传输诸如HTML的超媒体文档的应用层协议。它被设计用于Web浏览器和Web服务器之间的通信,但它也可以用于其他目的。 HTTP遵循经典的客户端-服务端模型,客户端打开一个连接以发出请求,然后等待它收到服务器端响应。HTTP是无状态协议,意味着服务器不会在两个请求之间保留任何数据(状态)。
Http1.0协议,客户端与web服务器建立连接后,只能获得一个web资源!
Http1.1协议,允许客户端与web服务器建立连接后,在一个连接上获取多个web资源!
前面讲过了三次握手,再看一下Http操作的一个流程了:
- 用户点击浏览器上的url(超链接),Web浏览器与Web服务器建立连接
- 建立连接后,客户端发送请求给服务器,请求的格式为: 统一资源标识符(URL)+协议版本号(一般是1.1)+MIME信息(多个消息头)+一个空行
- 服务端收到请求后,给予相应的返回信息,返回格式为: 协议版本号 + 状态行(处理结果) + 多个信息头 + 空行 + 实体内容(比如返回的HTML)
- 客户端接收服务端返回信息,通过浏览器显示出来,然后与服务端断开连接;当然如果中途 某步发生错误的话,错误信息会返回到客户端,并显示,比如:经典的404错误!
Http的几种请求方式
实际开发中我们用得较多的方式是Get和Post,但是实际开发可能还会用到其他请求方式。
- Get:请求获取Request-URI所标识的资源
- POST:在Request-URI所标识的资源后附加新的数据
- HEAD 请求获取由Request-URI所标识的资源的响应信息报头
- PUT:请求服务器存储一个资源,并用Request-URI作为其标识
- DELETE:请求服务器删除Request-URI所标识的资源
- TRACE:请求服务器回送收到的请求信息,主要用于测试或诊断
- CONNECT:保留将来使用
- OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项
Get和Post的对比
Get产生一个TCP数据包;Post产生两个TCP数据包。
对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
对于POST,浏览器先发送header,服务器响应100(continue),然后再发送data,服务器响应200(返回数据);
Http状态码合集
当然,这些状态码只是要给参考,实际上决定权在服务器端(后台的)手上,一种方案是请求后, 服务器返回给我们的是状态,或者另一种,在应用不用弄多语言版本的时候最好用,直接返回 一串结果信息的Json给我们,我们直接显示就好,这样可以偷懒不少!下面列下状态码合集,参考 下就好:
- 100~199 : 成功接受请求,客户端需提交下一次请求才能完成整个处理过程
- 200: OK,客户端请求成功
- 300~399:请求资源已移到新的地址(302,307,304)
- 401:请求未授权,改状态代码需与WWW-Authenticate报头域一起使用
- 403:Forbidden,服务器收到请求,但是拒绝提供服务
- 404:Not Found,请求资源不存在,这个就不用说啦
- 500:Internal Server Error,服务器发生不可预期的错误
- 503:Server Unavailable,服务器当前不能处理客户端请求,一段时间后可能恢复正常
HTTP Request Header请求头信息对照表:
Header |
解释 |
示例 |
Accept |
指定客户端能够接收的内容类型 |
Accept: text/plain, text/html |
Accept-Charset |
浏览器可以接受的字符编码集。 |
Accept-Charset: iso-8859-5 |
Accept-Encoding |
指定浏览器可以支持的web服务器返回内容压缩编码类型。 |
Accept-Encoding: compress, gzip |
Accept-Language |
浏览器可接受的语言 |
Accept-Language: en,zh |
Accept-Ranges |
可以请求网页实体的一个或者多个子范围字段 |
Accept-Ranges: bytes |
Authorization |
HTTP授权的授权证书 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Cache-Control |
指定请求和响应遵循的缓存机制 |
Cache-Control: no-cache |
Connection |
表示是否需要持久连接。(HTTP 1.1默认进行持久连接) |
Connection: close |
Cookie |
HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 |
Cookie: $Version=1; Skin=new; |
Content-Length |
请求的内容长度 |
Content-Length: 348 |
Content-Type |
请求的与实体对应的MIME信息 |
Content-Type: application/x-www-form-urlencoded |
Date |
请求发送的日期和时间 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expect |
请求的特定的服务器行为 |
Expect: 100-continue |
From |
发出请求的用户的Email |
From: user@email.com |
Host |
指定请求的服务器的域名和端口号 |
Host: www.zcmhi.com |
If-Match |
只有请求内容与实体相匹配才有效 |
If-Match: "737060cd8c284d8af7ad3082f209582d" |
If-Modified-Since |
如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 |
If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
If-None-Match |
如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 |
If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
If-Range |
如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag |
If-Range: "737060cd8c284d8af7ad3082f209582d" |
If-Unmodified-Since |
只在实体在指定时间之后未被修改才请求成功 |
If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Max-Forwards |
限制信息通过代理和网关传送的时间 |
Max-Forwards: 10 |
Pragma |
用来包含实现特定的指令 |
Pragma: no-cache |
Proxy-Authorization |
连接到代理的授权证书 |
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Range |
只请求实体的一部分,指定范围 |
Range: bytes=500-999 |
Referer |
先前网页的地址,当前请求网页紧随其后,即来路 |
Referer: http://blog.csdn.net/coder_pig |
TE |
客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息 |
TE: trailers,deflate;q=0.5 |
Upgrade |
向服务器指定某种传输协议以便服务器进行转换(如果支持) |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
User-Agent |
User-Agent的内容包含发出请求的用户信息 |
User-Agent: Mozilla/5.0 (Linux; X11) |
Via |
通知中间网关或代理服务器地址,通信协议 |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning |
关于消息实体的警告信息 |
Warn: 199 Miscellaneous warning |
HTTP Responses Header 响应头信息对照表:
Header |
解释 |
示例 |
Accept-Ranges |
表明服务器是否支持指定范围请求及哪种类型的分段请求 |
Accept-Ranges: bytes |
Age |
从原始服务器到代理缓存形成的估算时间(以秒计,非负) |
Age: 12 |
Allow |
对某网络资源的有效的请求行为,不允许则返回405 |
Allow: GET, HEAD |
Cache-Control |
告诉所有的缓存机制是否可以缓存及哪种类型 |
Cache-Control: no-cache |
Content-Encoding |
web服务器支持的返回内容压缩编码类型 |
Content-Encoding: gzip |
Content-Language |
响应体的语言 |
Content-Language: en,zh |
Content-Length |
响应体的长度 |
Content-Length: 348 |
Content-Location |
请求资源可替代的备用的另一地址 |
Content-Location: /index.htm |
Content-MD5 |
返回资源的MD5校验值 |
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Content-Range |
在整个返回体中本部分的字节位置 |
Content-Range: bytes 21010-47021/47022 |
Content-Type |
返回内容的MIME类型 |
Content-Type: text/html; charset=utf-8 |
Date |
原始服务器消息发出的时间 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
ETag |
请求变量的实体标签的当前值 |
ETag: "737060cd8c284d8af7ad3082f209582d" |
Expires |
响应过期的日期和时间 |
Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified |
请求资源的最后修改时间 |
Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
Location |
用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 |
Location: http://blog.csdn.net/coder_pig |
Pragma |
包括实现特定的指令,它可应用到响应链上的任何接收方 |
Pragma: no-cache |
Proxy-Authenticate |
它指出认证方案和可应用到代理的该URL上的参数 |
Proxy-Authenticate: Basic |