计算机网络之应用层、运输层核心知识

知识目录:

  1. OSI与TCP/IP各层的结构与功能
  2. TCP三次握手与四次挥手
  3. TCP协议与UDP协议的区别
  4. TCP协议如何保证可靠传输
  5. 从浏览器输入url地址到显示主页的全过程
  6. HTTP协议报文解析
  7. 各种协议与HTTP协议之间的关系
  8. HTTP长连接与短连接

一、OSI与TCP/IP各层的结构与功能

1.1 OSI体系结构

  • 应用层
  • 表示层
  • 会话层
  • 运输层
  • 网络层
  • 数据链路层
  • 物理层

1.2 TCP/IP四层协议

  • 应用层
  • 运输层
  • 网际层
  • 网络接口层

1.3 五层协议

  • 应用层
  • 运输层
  • 网络层
  • 数据链路层
  • 物理层

1.4 各层详情
应用层
应用层协议定义的是应用程序间的通信和交互的规则。对应不同的网络应用有不同的应用层协议,如:
域名系统(DNS),支持万维网应用的HTTP协议,支持电子邮件的SMTP协议。
我们将应用层交互的数据单元称为 报文。

域名系统:DNS是因特网的一项核心服务,它作为可以将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网,而不用去记住能够被机器直接读取的ip数串。

HTTP协议:超文本传输协议是互联网上应用最广泛的一种网络协议。所有的www文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

运输层
运输层的任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。由于一台主机可以同时运行多个线程,因此运输层有复用和分用的功能。复用即多个应用程序同时使用下层的运输层服务,分用即运输层可将数据交付给不同的应用程序。

运输层的两种主要协议:
TCP协议:面向连接的,可靠的数据传输服务。
UDP协议:提供无连接的,尽最大努力的数据传输服务。

TCP的主要特点:

  1. TCP是面向连接的。
  2. 每一条TCP连接只能有两个端点,即每条TCP连接都是点对点的。
  3. TCP提供可靠交付的服务。即通过TCP传输的数据:无差错,不丢失,不重复,按序到达。
  4. TCP提供全双工通信。即TCP允许通信双方的应用进程在任何时候都能发送数据,TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双方通信的数据。
  5. 面向字节流。简单说就是,虽然TCP与应用程序的交互是一次一个数据块,但是TCP将应用程序交付下来的数据块看成一段无结构的字节流。

UDP的主要特点:

  1. UDP是无连接的。
  2. UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的链接状态。
  3. UDP是面向报文的。
  4. UDP没有拥塞控制
  5. UDP支持一对一,一对多,多对多的交互通信
  6. UDP的首部开销小,只有8字节,而TCP的首部有20个字节。

网络层
网络层的任务就是选择合适的网间路由和交换节点,确保数据及时传送。

数据链路层
两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要使用专门的链路层协议。
在两个相邻节点之间传送数据时,数据链路层将网络层交下来的ip数据报组装成帧,在两个相邻节点上传送帧。每一帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等);

物理层
物理层的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。

二、TCP三次握手与四次挥手

2.1 三次握手
为了准确无误地将数据传送到目标处,TCP协议采用了三次握手协议。
在这里插入图片描述
三次握手最主要的目的就是确认对方和自己的发送和接收是正常的。
第一次握手:client什么都无法确认;server确认 了client发送正常
第二次握手:client确认了自己发送、接收正常,对方发送、接收正常; server确认了自己接收正常,对方发送正常。
第三次握手:client确认了自己发送、接收正常,对方发送、接收正常; server确认了自己发送、接收正常,对方发送、接收正常。

回传syn: 接收端回传syn是为了告诉发送端,我接收的信息就是你发送的信息
发送ack:双方通信必须都是无误的,回传了syn证明发送端到接收端的通道没问题,但是接收方到发送方的通道是否可靠还需要ack进行验证。

2.2 四次挥手
在这里插入图片描述

  1. 客户端发出连接释放报文,并且停止发送数据。 释放报文的首部 FIN = 1,序列号为 seq=u,此时客户端进入Fin-wait-1(终止等待1状态)
  2. 服务器端收到连接释放报文,发出确认报文。ACK=1,ack=u+1,且带上自己的序列号seq=v。此时服务端进入Close-wait(停止等待状态)
    客户端收到服务器的确认请求后,客户端进入Fin-wait-2(终止等待2状态)
  3. 服务器将最后的数据发送完毕后,就会发送连接释放报文。 Fin=1,ack=u+1,假定此时序列号seq=w,此时服务器进入Last-ACK(最终确认状态),等待客户端的确认。
  4. 客户端收到服务器端的连接释放报文后,发出确认。 ACK=1.ack=w+1,自己的序列号是seq=u+1。此时客户端就进入了TIME-WAIT(时间等待状态)。(超过2*最长报文段寿命时间后close)
    服务器端收到客户端发来的确认后,立即进入CLOSE状态。

总之,任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。

三、TCP协议与UDP协议的区别

在这里插入图片描述
四、TCP协议如何保证可靠传输

TCP协议保证可靠传输最主要的方式有三种:停止等待协议、流量控制、拥塞控制
4.1停止等待协议
基本原理:每发完一个分组就停止发送,等待确认。在收到确认后再发送下一个分组
注意:在停止等待协议中,若接收方收到重复分组,就直接将重复分组丢弃掉。但同时还要发送确认。
停止等待协议的所有情况如下:
1>无差错情况
发送方发送分组,接收方在规定时间内接收到,并回复确认,然后发送下一分组
在这里插入图片描述

2>出现差错情况(超时重传)
超时重传指发送方只要超过一段时间没有收到确认,就重传前面发送过的分组。因此没发送完成一个分组后需要设置一个超时计时器,其重传时间应比平均数据往返时间稍长一些。这种重传方式称为自动重传。
还有第二种重传方式,称为连续ARQ协议。
即发送方维持一个发送窗口,凡是位于发送窗口内的分组都可以发送出去,而不需要等待对方的确认。接收方一般采用累计确认,对于按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经确认收到了。这个时候发送方需要重新发送确认分组之后的分组。
在这里插入图片描述

3>确认丢失和确认迟到
确认丢失情况:
在这里插入图片描述
若接收方向发送方发送的确认信号丢失,则发送方在超时后会进行超时重传,当接收方再次接收到这一分组时,接收方会直接将此重复分组丢弃掉,同时,重新向发送方发送确认。

确认迟到情况
在这里插入图片描述
接收方发送方发送的确认迟迟没有到达,发送方超时重传,接收方丢弃重复分组,再次发送确认,发送方接收到确认后,进行下一分组的传输。过一段时间后,接收方第一次发送的确认到达发送方,这时候发送方收到重复确认,直接丢弃,不做任何反应。

4.2流量控制
TCP利用滑动窗口来实现流量控制。
流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以控制发送方发送窗口的大小,进而影响发送方的发送速率。若将窗口字段设置为0,则发送方不能发送数据。

4.3拥塞控制
TCP的拥塞控制主要采用了四种算法:慢开始,拥塞避免,快重传,快恢复

慢开始
当主机开始发送数据时,为避免将大量的数据注入到网络引起网络阻塞。采用从小到大逐渐增加发送窗口(即从小到大增加拥塞窗口数值cwnd)。cwnd初始值为1,每经过一个传播轮次,cwnd加倍。

拥塞避免
让cwnd缓慢增长,即每经过一个传播轮次,cwnd+1.

快重传和快恢复
快重传和快恢复算法,可以快速恢复丢失的数据包。在此算法下,当接收方接收到一个不按顺序的数据段,它会立即给发送方发送一个重复确认,若发送方接收到三个重复确认,则认为数据丢失,并立即重传这些数据。

在这里插入图片描述
拥塞避免的两种方式:
方式1:发生拥塞后慢开始
ssthresh阈值有一个初始值,首先是慢开始,达到阈值后开始采用拥塞避免。发生拥塞后cwnd变为1采用慢开始算法,此时阈值设置为发生拥塞是cwnd值的一半。
方式2:发生拥塞后快恢复
发生拥塞前同方式1一样。发送拥塞时,若发送方接收到三个重复确认,采用快恢复,即从新阈值(发送拥塞cwnd值的一半)直接开始,然后采用拥塞避免算法。

五、 从浏览器输入url地址到显示主页的全过程

  1. 在浏览器输入域名后,DNS解析为ip地址
  2. TCP连接
  3. 浏览器向web服务器发送http请求
  4. 服务器处理请求,并生成响应(html)
  5. 浏览器解析渲染界面
  6. 连接结束

六、 HTTP协议报文解析
HTTP报文类型分为请求报文和响应报文,基本格式都分为三部分。
基本格式:

GET / HTTP/1.1
Host: www.enjoytoday.cn
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://www.enjoytoday.cn/posts/326
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: bdshare_firstime=1466032270994; UM_distinctid=15c4ef2ac4e2e4-0d13269271b947-1b2a120b-1fa400-15c4ef2ac4f7b5; un=aGZjYWk=; comment_author=aGZjYWk=; comment_author_email=1710600212@qq.com; comment_author_url=http://www.enjoytoday.cn; c_id=dUhIaTlndmc4MVVYbjRQTGxMRTotMTpFODg3QjgzQjg1NjgxQjQxRUYxNjg2QzJFRkMyQjI2QQ==; JSESSIONID=ADBC8C3DADF6C815D778450C193C6637.ajp13_worker; Hm_lvt_ce55bfda158556585a8b7b246346c8ba=1498560244,1498739070,1498833193,1498917432; Hm_lpvt_ce55bfda158556585a8b7b246346c8ba=1498917597; CNZZDATA1262047894=1598545996-1495973145-%7C1498917578

username=hfcai&sex=man

请求报文:
1.请求行
位于首行,此部分给出了请求方法类型、请求的资源位置、HTTP协议版本。
http请求方式包括:get、post、head、put、delete。 常用的为 get 和 post
2.请求头部
主要是用于说明请求源、连接类型、以及一些Cookie信息等。大多数请求头并不是必需的,但Content-Length除外。对于POST请求来说 Content-Length必须出现。
常见的请求头部:

Accept:浏览器的内容类型列表
Accept-Charset:浏览器可接受的字符集
Accept-Language:浏览器可接受的语言类型
Content-Length:消息正文的长度
Host:目的主机的地址
Referer:发起请求的地址
User-Agent:用户信息,如浏览器版本等
Cookie:cookie数据
Connection:处理完本次请求后是否断开连接还是保持连接。 若值为“keep-alive”表示保持连接

3.请求正文
请求正文和请求头部通过一个空行进行隔开,一般用于存放post请求类型的请求正文。

一般形式为: username=he&sex=man

响应报文:
1.状态码部分
包括http版本号,响应返回状态码,响应描述
响应码:

1XX:信息提示,临时的响应
2XX请求成功,服务器端已接收到请求
3XX:重定位
4XX:客户端错误
5XX:服务器端错误

2.响应头部
主要返回服务器端的信息,以及一些cookie值
内容同请求头类似

3.响应体
该部分为请求得到的具体信息,可以为任何类型数据,一般返回的是html文件内容

七、各种协议与HTTP协议之间的关系

在这里插入图片描述
八、HTTP长连接与短连接

http/1.0为短连接:
客户端与服务器端没进行一次http操作,就建立一次连接,本次操作结束后,连接关闭。

http/1.1为长连接:
当一次http操作完成后,客户端与服务器端用于传输http数据的TCP连接会断开。客户端再次访问此服务器时,无需再次建立连接,而是会继续使用这一条连接。

参考来源:
《图解HTTP》
Snailclimb大神

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

喜鹊先生Richard

随缘~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值