请点击上面 ![16张图详解计算机网络协议]( "16张图详解计算机网络协议")
一键关注！
原文链接：https://blog.csdn.net/LiangJGo/article/details/90080011
很久很久以前，那时候还没有现在的外星人超级电脑，或者华为的P30。比较调皮的小明想要把自己机器上写好的一些个人游戏心得（如何玩好王者农药）发给小红（校花），希望博得芳心。小明个人比较勤，游戏总结心得总结的比较详细（大概有100M）。但是到底怎么才能从自己的机器上传给小红的机器呢，进过一番打听，他发现远在太平洋另一端的科学家已经发明了一种技术 物理层，专门用来解决小明这种单身狗问题。该层主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流(就是由1、0转化为电流强弱来进行传输，到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换)。这一层的数据叫做比特。
他很兴奋，通过一个月的努力终于搭建起了这个物理层。
然而上天却好像和小明开了一个玩笑，楼下的小润发超市的网线、光纤最近卖光了，但是这个物理层传输数据只能通过网线传输。到底怎么办。
此时，他体内的雄性激素促使着他的大脑以光速运转。终于他饿了，无奈得走去学校饭堂三楼吃麻辣烫。此时听到隔壁坐着的那位王叔叔（老王）说，科学家已经发明了一种技术可以通过无线电来传输。What？这不是完美解决了自己的困扰吗。小明连忙对隔壁老王说谢谢，老王留下了幸福的泪水！
右通过一番努力查资料，小明发现：这种技术可以通过电线我能发数据流，也可以通过其它介质来传输。然后还要保证了传输过去的比特流是正确的，有纠错功能。定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。
由于小明家离小红家比较远，无线电信号无法传输到哪里，但是这完全难不到小明。他通过在离小红家的路上搭建了多个节点（路由器，交换机），用于信号的传输。但是由于他有时候被雄性激素冲昏了头脑，搭建的信号节点有点乱，而且很多。那他又想用最短的路径来传输怎么办呢？在小明沮丧走回家的时候已深夜，他看见今天看到的那位王叔叔匆匆的从自己家走出来，他连忙拉住王叔叔，向他诉说自己的烦恼，希望王叔叔能给自己一些帮助。当小明说完后，王叔叔从紧张变为和蔼，和小明说：其实已经有人发明了网络层。即路由器，交换机那些具有寻址功能的设备所实现的功能。这一层定义的是IP地址，通过IP地址寻址。所以产生了IP协议。该层能选择最佳路径，这就是路由要做的事。
为了趁热打铁，小明通宵查资料来学习相关信息，并且简单搭建好网络层，开始传输数据，趁着传输过程好好睡一觉。当他起来的时候，噩梦才刚刚开始，因为他传输的数据太大（100M）只传输了一部分，而且断断续续的，有一部分数据根本传不出去。那怎么办？
“加一层传输层！”：王叔叔在楼下大声喊着，“资料在你妈妈的床头柜”，王叔叔继续说。小明连忙找到资料，上面写着：“
发正确的发比特流数据到另一台计算机了，但是当我发大量数据时候，可能需要好长时间，例如一个视频格式的，网络会中断好多次（事实上，即使有了物理层和数据链路层，网络还是经常中断，只是中断的时间是毫秒级别的）。
那么，我还须要保证传输大量文件时的准确性。于是，我要对发出去的数据进行封装。就像发快递一样，一个个地发。
例如TCP，是用于发大量数据的，我发了1万个包出去，另一台电脑就要告诉我是否接受到了1万个包，如果缺了3个包，就告诉我是第1001，234，8888个包丢了，那我再发一次。这样，就能保证对方把这个视频完整接收了。
例如UDP，是用于发送少量数据的。我发20个包出去，一般不会丢包，所以，我不管你收到多少个。在多人互动游戏，也经常用UDP协议，因为一般都是简单的信息，而且有广播的需求。如果用TCP，效率就很低，因为它会不停地告诉主机我收到了20个包，或者我收到了18个包，再发我两个！如果同时有1万台计算机都这样做，那么用TCP反而会降低效率，还不如用UDP，主机发出去就算了，丢几个包你就卡一下，算了，下次再发包你再更新。
TCP协议是会绑定IP和端口的协议，下面会介绍IP协议。”
通过如此这般的操作，他！小明同学终于把自己100M的游戏心得发送给了小红。
然而，小红根本不玩游戏。得知这个消息后，小明楞逼了。但是他没有放弃，而是把自己猜到小红喜欢的信息都发给他，但是小明每发一次，难道我每次都要调用TCP去打包，然后调用IP协议去找路由，这一来一回就是一天，那怎么办呢？
他又翻了翻王叔叔的笔记本资料，写着：会话层可以帮助我们建立和管理应用程序之间的通信，封装了调用TCP去打包，然后调用IP协议去找路由等操作，如此一来，他只需要十几二十分钟就能够成功搭建好传输数据的机器。
有一次，小明传了一份数据，是关于如何选购化妆品的文章，小红对此非常感兴趣，但是当小红想用自己的window开该文件时发现根本无法打开，后来小红在下课的时候和小明说自己无法打开这个文件，小明想自己用Linux系统明明完整地发送给了小红啊，那就奇怪了，但是出于耍帅，小明只是轻轻地说“我放学后再发你一份！”。
这时虽然小明不知道是出了什么问题，但是他坚信老王叔叔的资料笔记会有答案的。
果然！上清清楚楚的写着：“现在我能保证应用程序自动收发包和寻址了。但是我要用Linux给window发包，两个系统语法不一致，就像安装包一样，exe是不能在linux下用的，shell在window下也是不能直接运行的。于是需要表示层（presentation），帮我们解决不同系统之间的通信语法问题。”
小明立即用了一个通宵手动搭好了表示层，传输了一份完美的文件给小红。
7.应用层(文件传输，电子邮件，文件服务，虚拟终端)
TCP/IP协议是由七层模型简化成四层而来。（TPC/IP协议其实泛指了四层模型中的全部协议，区别开TCP协议，IP协议）
-
七层有底向上分别是：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
-
简化后的四层分别是：主机到网络层（比特）、网络层（数据帧）、传输层（数据包）、应用层（数据段）。
每一层对于上一层来讲是透明的，上层只需要使用下层提供的接口，并不关心下层是如何实现的。
网络层是主机与主机之间的通讯，而传输层则是进程之间的通讯。
应为进程是资源分配的基本单位，计算机之间的信息传输也只是一台计算机的进程传输到另外一台计算机的进程中。
那就是通过IP协议来完成的（复用，多个进程都可以把信息通过传输层到IP层，再传输到另外一台计算机中）。
那就是用端口（分用，到达另外一台计算机后还要通过端口号找到对应进程）。
-
-
-
长度，首部长度 + 用户数据包的长度（可以没有数据包，所用最小值为8）
-
检验和，检查UDP用户数据传输中是否与错，有错就丢弃（检查首部长度 + 用户数据包）
-
面向连接的协议。数据传输之前都要建立连接（三次挥手），数据传输结束都要释放连接（四次挥手）
-
一条TCP连接只能有两个端点，端点是socket（结构 IP地址:端口号），并非主机或进程。
其实TCP是依赖停止 等待协议和连续ARQ 协议+滑动窗口协议才达到可靠的目的
-
-
工作原理：客户发送一次数据到服务端，必须等到服务端响应后才发第二次数据，中间的等待时间RTT占了大部分时间，中间如果出现差错（超时或确认丢失）都需要从新传输。
-
连续ARQ协议工作原理：维持一个发送窗口（记录了当前可以发送的数据包数量n），在窗口内的数据都可以连续发送出去，服务器只在接收完一个发送窗口的数据后才回响应（累计确认），发送端接收到响应就把发送窗口移动n位，开始新一轮数据发送。
以上只是简单了解TCP协议的发送流程，如果要清楚发送细节，必须知道TCP报文首部
虽然说TCP是面向字节流的，但是TCP传输的数据单元却是报文段，报文段由首部和数据两部分组成，如图：
2.序号（占4字节）：TCP连接传输的数据每一个字节都有一个序号，而一个报文段可能会有多个字节的数据，这个序号指的是TCP报文段中起始的序号，下一个报文段的序号则是该序号加上报文数据长度（三次握手和四次挥手时说的SYN或ACK会消耗一个序号就是指该序号）
3.确认号（占4字节）：因为一次数据传输会分成多个报文段，接收方接收完一次报文段后如果要发送确认（有可能不用确认，因为是接收完发送窗口的报文段才确认的），则会携带一个确认号，表示接收方想要接收的下一个报文的序号
4.数据偏移（占4字位）：数据部分的起始位置离报文段起始位置的距离，就是报文首部的长度，单位是4字节，所以4位能表示最大值是十进制的15，就是15 x 4字节 = 60字节，TCP报文首部最大长度为60字节
6.紧急URG：当URG=1时紧急数据才有效。注意，这里URG并不是紧急数据，只是一个标志，标志着紧急数据是否有效
7.确认ACK：当ACK=1时确认号才有效，当建立连接后全部传输的报文都要把ACK设置为1
8.推送PSH：接收方机器会有一个接收，当接收缓存慢了才回把接收到的数据交付到接收应用进程中，而如果发送端把报文的PSH设为1，接收方接收到该报文会立即交付到应用的进程中
9.复位RST：两个作用，1、当RST=1时，表示TCP连接中出现严重差错，必须释放连接，然后重新建立运输连接。2、当RST=1时，拒绝一个非法的报文段或拒绝打开一个连接。
10.同步SYN：用于同步序号（告诉另外一方，他们之间从该序号开始传输报文段），当SYN=1,ACK=0表示这时一个连接请求报文。
11.终止FIN：用于释放一个连接。当FIN=1时，表明此报文的发送方的数据已经发送完毕，并要求释放运输连接。
12.窗口（占2字节），是一个接收窗口，接收方允许发送方发送的数据量
13.检验和（占2字节）：检验接收过来的报文段（报文首部和用户数据）是否有误
14.紧急指针（占2字节）：当URG=1时才有效，指出紧急数据未尾位置（开始位置是整个报文段中用户数据的开头）
-
发送窗口有两部分组成，已发送的报文段 和 能够发送但未发送的报文段（等待已发送报文段全部接收完发回来的确认就可以发送了）
-
当收到确认后发送窗口会向右移动到7位置，作为窗口的起始位置。
-
发送窗口，发送窗口有可能会收缩（因为接收窗口有可能因为接收缓存不够而变小）
采用一个根据RTT动态计算的时间，并不是直接采用一个固定的时间
RTT：发送一个报文段到收到对应的ACK所花费的时间
如果发生了重传 ，这次的RTT会让RTTs会变大，此时是不会用该RTT来计算RTTs的
当数据传输过程中，接收方可能会未按顺收到部分报文段，此时序号告诉发送方从新传输这些报文段，SACK选项就是用于告诉发送方需要传输那些报文段的
主动建立连接的一端叫客户端，被动等待连接建立的一方叫服务器
每次发送一个seq时，都会消耗一个序号，所以会发现在确认时，ack总等于另一端请求的seq+1
在很久很久以前，A发了一个连接请求给B，但是网络滞留的原因，请求没有到达B，所以B也没有确认返回给A，所以A右发送了一个连接请求给B，此时B收到了连接请求并返回了一个确认给A，此时连端开始愉快的数据传输之旅。当传输结束时，分别断开连接，各自干各自的活儿。但是过了一段时间，之间滞留在网络中的A发出的连接请求到达了B中，B以为A又要传输数据，便右回了一个确认给A，但是A并不需要输出传输，也没有理会这个确认，而B却在傻傻等待A传输数据，这个就会浪费B的资源。
但是如果有第三次A的确认，A这个滞留的连接传给B，B返回一个确认，但是A不想传输数据了，便没有回一个确认给B（第三次握手），B没有收到该确认也不会等待A传输数据。
第一次挥手：客户端发送连接，FIN=1标志着A已经完成了数据的发送。
第二次挥手：B回了一个确认，此时A与B的发送连接就断开了。
第三次挥手：因为TCP连接是全双工通信的，B还保留着一个对A大发送连接，如果等到B也不需要发送数据给A时，B会发送一个连接给A，seq等于一个大于或等于v的值（因为A与B断开发送连接到B与A断开发送连接期间有可能B向A发送了数据，就是消耗序号）。
第四次挥手：当A收到B的连接时，要回一个响应给B，但是此时会有一个2MSL长的等待时间，时间一过，就真正的断开与B的全部连接了。
当A发送确认给A后，如果此时出现了一些状况（连接被丢弃等），确认无法到达B中，B会重新发送一个连接给A，但是A就停止了，B就一直等待（其实有一个保活时间）。
如果有了这个等待时间，就算A的ACK确认丢失了，B也会再从新发送一个连接给A，A接收到该连接后，会从新计算等待时间。A会再确认一次
-
-
-
-
-
无状态，没有记忆的，请求完一次后，就结束了，后面如果要再获得数据必须从新请求
请求头部：用于设置请求的的一些参数如：ContentType
请求空行：就算请求数据为空，都要有空行，表示请求首部的结束
HTTP报文层面：GET请求信息放在URL中，POST放在报文体中
数据库层面：GET符合幂等性和安全性，POST不符合
-
在使用一些需要登录的网站时，每次访问，都会需要验证个人信息，即登录。这样做比较繁琐，能否将个人的账号和密码存起来，访问的时候直接用存取来的个人信息进行验证呢？解决这个问题的就是Cookie和Session
-
Cookie：通过客户端（浏览器）来缓存个人信息。当用户第一次登录时，服务器会将个人信息放在了响应中， 浏览器接收到响应时候会将个人信息以Cookie的形式访问浏览器中保存起来，在下一次访问服务器的时候会带上该Cookie，Cookie中有个人信息，服务器能解析出来，所以不同再次登录验证了。（不够安全，对服务器的开销小）
-
Session通过服务端来缓存信息，根据请求中是否包含Session id的字段，如果不存在则创建一个，并返回给浏览器缓存起来。如果存在则通过该Session id在服务器存储中获得对应的Session信息，直接验证。（安全，服务器的开销变大）
3、连接方式不同，HTTPS默认使用443端口，HTTP使用80端口
4、HTTPS = HTTP + 加密+认证+完整性保护，较HTTP安全
其实也不一定就安全，原因是用户不会再访问时候加上http:// 或 https://, 浏览器就默认会加上http://，然后通过转发的方式转成https:// 这个过程http就有可能会被劫持了。
此时会用到一个技术 HSTS(HTTP Strict Transort Security)
![16张图详解计算机网络协议]( "16张图详解计算机网络协议")
欢迎扫描关注【天億网络安全】公众号，及时了解更多网络安全知识
原文始发于微信公众号（天億网络安全）：16张图详解计算机网络协议
一键关注！
评论