zoukankan      html  css  js  c++  java
  • 图解tcp ip总结

    ### 图解tcp ip总结

    ##### 为什么会出现网络系统?
    - 连接不同的计算机设备

    ##### 为什么会出现协议?
    - 协议是一种约定,在计算机世界 通过约定实现互通,就好像英语之余所有语言一样

    ##### 为什么要标准化?
    - 计算机中一切都需要自己实现,只有标准化后,同一个问题不会因为出现不同的解决方案而导致额外精力的浪费

    ##### 为什么要分层
    - 一种解耦的方式



    ### 网络传输系统

    ##### 物理层
    - 没什么好说的,就是一推电线或者电磁波

    ##### 数据链路层
    - 数据链路层要达到的目标是实现一台机器可以向另外一台机器发送信息,实现的关键就是mac地址,数据链路层 通过学习知道了网络中不同设备的mac地址,等到进行数据传输的时候,就可以根据mac地址发送信息给指定机器。数据链路层的核心协议是环路。

    ##### 网络层
    - 网络层要做的是通过ip识别机器,之所以在mac地址上再抽象出一层地址系统是为了便于维护,而网络层的核心设备是路由器,每一台设备接入路由器后,路由器都会将该设备的mac地址与一个ip设备对应,这样在接收到信号后 路由器就会根据这种对应关系发送信号给指定设备。网络层的核心协议是以太网。

    ##### 传输层
    - 传输层实现程序通信,通过端口号的定义,使得每一个程序只要通过该端口 即可与另外一台计算机的某程序进行通信。同时传输层还负责数据的可靠传输。

    ##### 会话层
    - 会话层负责连接的创建与中断。

    ##### 表示层
    - 负责数据的转码

    ##### 应用层
    - 负责具体应用的使用



    ### 路由系统

    ##### 路由
    - 网络世界通过路由进行联通,路由可以连接其他路由也可以连接主机,路由通过互联组成一个巨大的网络,路由会定期将自己所链接的信息广播给其他路由,这样网络中所有的路由 对于网络世界的连接信息都是清楚的,这有利于 在信号传输的时候 最优路径的选择。



    ### 应用层协议

    ##### 定义
    - tcp只是实现了数据的可靠传输,但是 在具体的生活场景中,数据传输是根据业务场景不但变化的,人类在长期的实践中,针对某一种通信场景提炼出来的连接规范,通过将这种规范定义下来,使得所有人都遵守这种协议,可以大大的提高网络中 不同应用的互通性。
     
    - http: 超文本传输协议
    - talent:远程登陆
    - ssh:加密;连接
    - ftp:文件传输
    - smtp:邮件发送
    - RTP:实时通信协议
    - p2p:端对端传输



    ### 关于tcp可靠传输

    ##### 连接与断开连接
    - 连接:连接的本质是指 双方需要确保对方可以收到自己的信息
    - 断开连接:断开连接的本质是指 数据在传输完成后才可以断开连接
    - ACK:确认信号
    - SYN:建立连接信号
    - FIN:关闭连接信号

    ##### 三次握手
    - 客户端向服务器发送一个SYN J,表示希望建立连接
    - 服务器向客户端响应一个SYN K,并对SYN J进行确认ACK J+1,表示我收到了你的信号,并也发送一个SYN看看你是否可以收到我的信号
    - 客户端再想服务器发一个确认ACK K+1,表示我也可以收到你的信号

    ##### 四次握手
    - 主动关闭方发送关闭请求,表示不会再发送新的数据,但是会重发旧数据和接收数据
    - 被动方接收到信号后,发送一个ACK给对方,确认序号为收到序号+1,表示我知道了
    - 被动方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。
    - 主动关方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1

    ##### 滑动窗口
    - 设想发送端和接受端 是两组链条,其中发送端有果实,而接受端是空的,我们设计一个窗子,这个窗子一行可以容纳10个果实,于是我们首先把窗子放在 发送端链条的起始位置,然后 刷的一下 10个果实全部都飞出去了,飞到对面接收到的窗子里面去了,对面的接收到收到了 1 2 3 4 5 6 8 9 10,这9个果实,于是接受端把 8 9 10这三个缓存起来,并告诉接收到 收到了哪些果实,接受端 一看 1 2 3 4 5 6都收到了,于是就把这6个果实的位置从窗口移出去,具体的表现就是窗口滑动到了7号位置,不断重复这个行为,窗口会不断滑动,所以叫滑动窗口。
    - https://www.jianshu.com/p/62940de97ca5

    ##### 流量控制
    - 定义:如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。为了避免分组丢失,控制发送者的发送速度,使得接收者来得及接收,这就是流量控制
    - 实现原理:主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送。当发送者收到了一个窗口为0的应答,发送者便停止发送,等待接收者的下一个应答
    - 死锁问题:当发送者收到了一个窗口为0的应答,发送者便停止发送,等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失,发送者一直等待下去,而接收者以为发送者已经收到该应答,等待接收新数据,这样双方就相互等待,从而产生死锁。
    - 死锁解决:为了避免流量控制引发的死锁,TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口,则重置该计时器继续等待;若窗口不为0,则表示应答报文丢失了,此时重置发送窗口后开始发送,这样就避免了死锁的产生。

    ##### 拥塞控制
    - 定义:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况;
    - 实现原理:发送方维持一个叫做拥塞窗口cwnd,拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口,另外考虑到接受方的接收能力,发送窗口可能小于拥塞窗口。
    慢开始:不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小。
    - https://zhuanlan.zhihu.com/p/37379780

    ##### 拥塞避免
    - 把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半,当检测到网络拥堵的时候,把拥塞窗口cwnd重新设置为1,重新执行慢开始
    慢开始门限ssthresh:当cwnd<ssthresh时,使用慢开始算法。当cwnd>ssthresh时,改用拥塞避免算法。当cwnd=ssthresh时,慢开始与拥塞避免算法任意

    ##### 快重传算法
    - 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方,可提高网络吞吐量约20%)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。

    ##### 快恢复算法
    - 当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半(为了预防网络发生拥塞)。但是接下去并不执行慢开始算法
    考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh减半后的值,然后执行拥塞避免算法,使cwnd缓慢增大。


    ### 总结
    - 传输层以下不需要开发者自己实现,会话层已经形成共识使用socket,开发者唯一可以做的就是使用应用层协议,同时也可以创建自己的应用层协议,只要通信双方计算机上的程序都认可该协议即可。

    - 路由节点是网络中的基本节点,同时也组成了一个去中心化的网络系统,路由节点通过定时广播自己的连接信息是的网络中其他节点都可以了解整个系统的连接信息。这类似于一种高级的智能系统。

    - 通过抽象出7层模型,是的每一层的更改不会影响到整个系统。比如将电线换成无线传输 对于整个传输不会产生任何影响。

    - 协议和标准化是工业级开发的必备路径。
  • 相关阅读:
    整理了一份React-Native学习指南
    新建项目
    spring security 匿名登录
    spring security remember me实现自动登录
    spring security为不同用户显示各自的登录成功页面
    spring security 管理会话 多个用户不可以使用同一个账号登录系统
    spring security 图解过滤器的使用
    spring security 判断用户是否登录 只要登录就可以访问资源
    spring security动态管理资源结合自定义登录页面
    spring security自定义拒绝访问页面
  • 原文地址:https://www.cnblogs.com/mrzhu/p/13331158.html
Copyright © 2011-2022 走看看