TCP/IP协议、UDP协议、 Http协议

 

开放式系统互联通信参考模型(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地址

 

 

 DNSDomain 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

posted @ 2019-04-21 16:45  NeoWu50  阅读(...)  评论(...编辑  收藏