一切不可能,终将化为寻常。
喜欢一我的就说喜欢,心存感恩就说谢谢;说反话并不会引发别人的关注,只会把人越推越远。
本文已收入至个人 GitHub仓库,欢迎Star: github.com/JavaKongHao,里面也有我我的联系方式有什么问题也能够直接找我。
注:计算机(硬件)->os->应用软件css
互联网的本质就是一系列的网络协议。互联的概念,就像是两个不一样语种国家的人,让他们沟通交流的就必须定义统一语言,在人类社会中英语就是这个做用。那么在计算机中,天然也须要一种规范,网络通讯协议就这么诞生了。html
C/S (Client/Server),是指客户端和服务器结构
B/S (Browser/Serve),是指浏览器和服务器结构
复制代码
两种架构各有优点,但不管那种架构,都离不开网络的支持。git
一、 通讯协议:计算机网络通讯必须遵照的规则。github
1.UDP协议:面向无链接、效率高、不保证数据完整
2.TCP协议:面向链接、效率低、保证数据完整
复制代码
二、 IP地址:网络中设备的惟一标识。(分类IPv4,IPv6) (获取ip地址:命令台键入ipconfig) 特殊IP地址:是回送地址,本机地址,通常用于测试编程
三、 端口号:软件一打开,操做系统会为网络软件分配一个端口号。 (普通应用程序使用1024以上的端口号) 使用IP地址加端口号,就能够保证数据正确无误的发送到对方计 算机的制定软件了。设计模式
tips:2019年11月26日,全球全部43亿个IPv4地址已分配完毕。
复制代码
使用IP地址加端口号,就能够保证数据正确无误的发送到对方计算机的指定软件了。浏览器
1.应用层:应用程序间沟通的层,如简单电子邮件传输(SMTP)、文件传输协议(FTP)、网络远程访问协议(Telnet)等。缓存
2.传输层:在此层中,它提供了节点间的数据传送,应用程序之间的通讯服务,主要功能是数据格式化、数据确认和丢失重传等。如传输控制协议(TCP)、用户数据报协议(UDP)等,TCP和UDP给数据包加入传输数据并把它传输到下一层中,这一层负责传送数据,而且肯定数据已被送达并接收。安全
3.网际层:负责提供基本的数据封包传送功能,让每一块数据包都可以到达目的主机(但不检查是否被正确接收),如网际协议(IP)。服务器
4.网络接口层(主机-网络层):接收IP数据报并进行传输,从网络上接收物理帧,抽取IP数据报转交给下一层,对实际的网络媒体的管理,定义如何使用实际网络(如Ethernet、Serial Line等)来传送数据。
1.UDP协议:用户数据报协议,面向无链接链接通讯协议,因为使用UDP协议消耗资源小,通讯效率高,可能会出现数据丢失因此一般都会用于音频、视频和普通数据传输。(数据包限制在64Kb)
2.TCP协议:传输控制协议,面向链接的通讯协议。面向链接的特性,TCP协议能够保证传输数据的安全,因此应用 十分普遍,例以下载文件、浏览网页。
过程如图所示:
CLOSED(关闭)
状态。本例中
A(Client)
主动打开链接,
B(Server)
被动打开链接。 一开始,B 的 TCP 服务器进程首先建立传输控制块TCB,准备接受客户端进程的链接请求。而后服务端进程就处于
LISTEN(监听)
状态,等待客户端的链接请求。若有,当即做出响应。
第一次握手:A 的 TCP 客户端进程也是首先建立传输控制块 TCB。而后,在打算创建 TCP 链接时,向 B发出链接请求报文段,这时首部中的同步位 SYN=1
,同时选择一个初始序号 seq = x
。TCP 规定,SYN 报文段(即SYN = 1 的报文段)不能携带数据,但要消耗掉一个序号。这时,TCP 客户进程进入 SYN-SENT(同步已发送)
状态。
第二次握手:B 收到链接请求报文后,若是赞成创建链接,则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1,确认号是 ack = x + 1
,同时也为本身选择一个初始序号 seq = y
。请注意,这个报文段也不能携带数据,但一样要消耗掉一个序号。这时 TCP 服务端进程进入SYN-RCVD(同步收到)
状态。
第三次握手:TCP 客户进程收到 B 的确认后,还要向 B 给出确认。确认报文段的 ACK 置 1,确认号 ack = y + 1
,而本身的序号 seq = x + 1
。这时 ACK报文段能够携带数据。但若是不携带数据则不消耗序号,这种状况下,下一个数据报文段的序号还是 seq = x + 1
。这时,TCP 链接已经创建,A 进入 ESTABLISHED(已创建链接)
状态。
第一次挥手:A 的应用进程先向其 TCP 发出链接释放报文段,并中止再发送数据,主动关闭 TCP 链接。A 把链接释放报文段首部的终止控制位 FIN 置 1,其序号 seq = u(等于前面已传送过的数据的最后一个字节的序号加 1),这时 A 进入 FIN-WAIT-1(终止等待1)
状态,等待 B 的确认。请注意:TCP 规定,FIN 报文段即便不携带数据,也将消耗掉一个序号。
第二次挥手:B 收到链接释放报文段后当即发出确认,确认号是 ack = u + 1
,而这个报文段本身的序号是 v(等于 B 前面已经传送过的数据的最后一个字节的序号加1),而后 B 就进入 CLOSE-WAIT(关闭等待)
状态。TCP 服务端进程这时应通知高层应用进程,于是从 A 到 B 这个方向的链接就释放了,这时的 TCP 链接处于半关闭(half-close)
状态,即 A 已经没有数据要发送了,但 B 若发送数据,A 仍要接收。也就是说,从 B 到 A 这个方向的链接并未关闭,这个状态可能会持续一段时间。A 收到来自 B 的确认后,就进入 FIN-WAIT-2(终止等待2)
状态,等待 B 发出的链接释放报文段。
第三次挥手:若 B 已经没有要向 A 发送的数据,其应用进程就通知 TCP 释放链接。这时 B 发出的链接释放报文段必须使 FIN = 1。假定 B 的序号为 w(在半关闭状态,B 可能又发送了一些数据)。B 还必须重复上次已发送过的确认号 ack = u + 1
。这时 B 就进入 LAST-ACK(最后确认)
状态,等待 A 的确认。
第四次挥手:A 在收到 B 的链接释放报文后,必须对此发出确认。在确认报文段中把 ACK 置 1,确认号 ack = w + 1
,而本身的序号 seq = u + 1
(前面发送的 FIN 报文段要消耗一个序号)。而后进入 TIME-WAIT(时间等待)
状态。请注意,如今 TCP 链接尚未释放掉。必须通过时间等待计时器设置的时间 2MSL
(MSL:最长报文段寿命)后,A 才能进入到 CLOSED
状态,而后撤销传输控制块,结束此次 TCP 链接。固然若是 B 一收到 A 的确认就进入 CLOSED
状态,而后撤销传输控制块。因此在释放链接时,B 结束 TCP 链接的时间要早于 A。
第一次握手:Client
什么都不能确认;Server
确认了对方发送正常,本身接收正常
第二次握手:Client
确认了:本身发送、接收正常,对方发送、接收正常;Server
确认了:对方发送正常,本身接收正常
第三次握手:Client
确认了:本身发送、接收正常,对方发送、接收正常;Server
确认了:本身发送、接收正常,对方发送、接收正常
第一次挥手:主机1(可使客户端,也能够是服务器端),设置Sequence Number
和Acknowledgment Number
,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1
状态;这表示主机1没有数据要发送给主机2了
第二次挥手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number
为Sequence Number
加1;主机1进入FIN_WAIT_2
状态;主机2告诉主机1,我“赞成”你的关闭请求
第三次挥手:主机2向主机1发送FIN报文段,请求关闭链接,同时主机2进入LAST_ACK
状态
第四次挥手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,而后主机1进入TIME_WAIT
状态;主机2收到主机1的ACK报文段之后,就关闭链接;此时,主机1等待2MSL
后依然没有收到回复,则证实Server
端已正常关闭,那好,主机1也能够关闭链接了。
当服务器执行第二次挥手以后, 此时证实客户端不会再向服务端请求任何数据, 可是服务端可能还正在给客户端发送数据(多是客户端上一次请求的资源尚未发送完毕),因此此时服务端会等待把以前未传输完的数据传输完毕以后再发送关闭请求。
一、最优分配:应用数据被分割成TCP认为最适合发送的数据块。这和UDP彻底不一样,应用程序产生的数据报长度将保持不变。
二、确认响应:当TCP收到发自TCP链接另外一端的数据,它将发送一个确认。其间可能由于对包校验而产生延迟。
三、拥塞控制:当网络拥塞时,减小数据的发送。
四、超时重传:当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。若是不能及时收到一个确认,将重发这个报文段。
五、接收校验: TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程当中的任何变化。若是收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段。
六、失序重排:TCP报文段做为IP数据报来传输,而IP数据报的到达可能会失序,所以TCP报文段的到达也可能会失序。若是必要,TCP将对收到的数据进行从新排序,将收到的数据以正确的顺序交给应用层。
七、丢弃重复数据:既然IP数据报会发生重复,TCP的接收端必须丢弃重复的数据。
八、流量控制:TCP还能提供流量控制。TCP链接的每一方都有固定大小的缓冲空间。TCP的接收端只容许另外一端发送接收端缓冲区所能接纳的数据。这将防止较快主机导致较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议
HTTP协议即超文本传送协议(Hypertext Transfer Protocol ),是Web联网的基础,也是手机联网经常使用的协议之一,HTTP协议是创建在TCP协议之上的一种应用。
HTTP链接最显著的特色:是客户端发送的每次请求都须要服务器回送响应,在请求结束后,会主动释放链接。从创建链接到关闭链接的过程称为“一次链接”。
1.短链接:在HTTP 1.0中,客户端的每次请求都要求创建一次单独的链接,在处理完本次请求后,就自动释放链接。
2.长链接:在HTTP 1.1中则能够在一次链接中处理多个请求,而且多个请求能够重叠进行,不须要等待一个请求结束后再发送下一个请求。
tip:使用长链接的http会在响应头加上 Connection: keep-alive
复制代码
因为HTTP在每次请求结束后都会主动释放链接,所以HTTP链接是一种“短链接”,要保持客户端程序的在线状态,须要不断地向服务器发起链接请求。一般的作法是即时不须要得到任何数据,客户端也保持每隔一段固定的时间向服务器发送一次“保持链接”的请求,服务器在收到该请求后对客户端进行回复,代表知道客户端“在线”。若服务器长时间没法收到客户端的请求,则认为客户端“下线”,若客户端长时间没法收到服务器的回复,则认为网络已经断开。
1. 1xx:服务器就收客户端消息,但没有接受完成,等待一段时间后,
发送1xx状态码
2. 2xx:成功。
* 200(成功)
3. 3xx:重定向。
* 302(重定向),
* 304(访问缓存)
4. 4xx:客户端错误。
* 404(请求路径没有对应的资源)
* 405:请求方式没有对应的doXxx方法
5. 5xx:服务器端错误
* 500(服务器内部出现异常)
复制代码
cookie
1. cookie存储数据在客户端浏览器
2. 浏览器对于单个cookie 的大小有限制(4kb) 以及 对同一个域名下的总cookie数量也有限制(20个)
3. cookie通常用于存储少许的不太敏感的数据(建议手动设个失效时间和path)
4. 在不登陆的状况下,完成服务器对客户端的身份识别(建议作加密)
session
1. session用于存储一次会话的屡次请求的数据,存在服务器端
2. session能够存储任意类型,任意大小的数据
3. session做用范围一次会话(屡次请求,从访问这个网站开始 到关闭浏览器结束)
cookie和session区别:
1. session存储数据在服务器端,Cookie在客户端
2. session没有数据大小限制,Cookie有
3. session数据安全,Cookie相对于不安全
4. Session是依赖于Cookie的
5. Session是域对象,Cookie不是域对象
复制代码
1.https协议须要到CA申请证书,大多数状况下须要必定费用
2.Http是超文本传输协议,信息采用明文传输,Https则是具备安全性SSL加密传输协议
3.Http和Https端口号不同,Http是80端口,Https是443端口
4.Http链接是无状态的,而Https采用Http+SSL构建可进行加密传输、身份认证的网络协议,更安全。
5.Http协议创建链接的过程比Https协议快。由于Https除了Tcp三次握手,还要通过SSL握手。链接创建以后数
据传输速度,两者无明显区别。
复制代码
socket(套接字)是通讯的基石,是支持TCP/IP协议的网络通讯的基本操做单元。
Socket是应用层与TCP/IP协议族通讯的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来讲,一组简单的接口就是所有,让Socket去组织数据,以符合指定的协议。(简单的理解:socket就是对下层的封装,供上层更简便的使用)
1.输入url
地址后,首先进行DNS
解析,将相应的域名解析为IP地址
;
2.客户端根据IP地址
去寻找相应的服务器;
3.与服务器进行TCP的三次握手
;
4.客户端找到相应的资源库
;
5.根据资源库返回页面信息;
6.浏览器根据自身的执行机制解析页面;(浏览器的执行机制?重绘?重排?......)浏览器解析页面时,会找到每个文件夹(css、js、html、img......),每个文件夹下的资源会从新走到第二步,去找到相应的服务器,而后一步步执行。
7.最后服务器将解析信息返回给客户端,进行TCP的四次挥手
。
图片来源:《图解HTTP》:
空号 | 文 【原创】【转载请联系本人】 若是本篇博客有任何错误,请批评指教,不胜感激 !本文已收入至个人 GitHub仓库,欢迎Star: github.com/JavaKongHao,里面也有我我的联系方式有什么问题也能够直接找我。