TCP共有6个标志位,分别是:
SYN(synchronous),建立联机。
ACK(acknowledgement),确认。
PSH(push),传输。
FIN(finish),结束。
RST(reset),重置。
URG(urgent),紧急。
TCP三次握手
第一次握手,客户端发了个连接请求消息到服务端,服务端收到信息后知道自己与客户端是可以连接成功的,但此时客户端并不知道服务端是否已经接收到了它的请求,所以服务端接收到消息后的应答,客户端得到服务端的反馈后,才确定自己与服务端是可以连接上的,这就是第二次握手。第三次握手是为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误。
譬如发起请求遇到类似这样的情况:客户端发出去的第一个连接请求由于某些原因在网络节点中滞留了导致延迟,直到连接释放的某个时间点才到达服务端,这是一个早已失效的报文,但是此时服务端仍然认为这是客户端的建立连接请求第一次握手,于是服务端回应了客户端,第二次握手。
如果只有两次握手,那么到这里,连接就建立了,但是此时客户端并没有任何数据要发送,而服务端还在傻傻的等候佳音,造成很大的资源浪费。所以需要第三次握手,只有客户端再次回应一下,就可以避免这种情况。
完成三次握手,客户端与服务器开始传送数据
具体可参考 https://baijiahao.baidu.com/s?id=1614404084382122793&wfr=spider&for=pc
什么情况服务端不返回ACK
当开启了tcp_tw_recycle选项后,当连接进入TIME_WAIT状态后,会记录对应远端主机最后到达分节的时间戳。如果同样的主机有新的分节到达,且时间戳小于之前记录的时间戳,即视为无效,相应的数据包会被丢弃(rfc1323)。
服务器同时设置tcp_timestamps=1和tcp_tw_recycle=1,就会缓存每个客户端TCP通信数据包中最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被直接丢弃。
TCP四次挥手
(1) TCP客户端发送一个FIN报文,用来关闭客户到服务器的数据传送。
(2) 服务器收到这个FIN报文,它发回一个ACK报文,确认序号为收到的序号加1。和SYN一样,一个FIN报文将占用一个序号。
(3) 服务器关闭客户端的连接,发送一个FIN给客户端。
(4) 客户端发回ACK报文确认,并将确认序号设置为收到序号加1。
为什么要四次挥手?
断开连接的时候,一个方向的断开,只是说明该方向数据已传输完毕,而另一个方向或许还有数据,所以得等到另一个方向数据也全部传输完成后,才能执行第三次挥手
TCP是全双工模式,这就意味着,当主机1发出FIN
报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK
报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN
报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。
四次挥手 为什么需要等待2msl
这最主要是因为两个理由:
1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。
2、他还可以防止已失效的报文段。客户端在发送最后一个ACK之后,再经过经过2MSL,就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。
注意:在服务器发送了FIN-ACK之后,会立即启动超时重传计时器。客户端在发送最后一个ACK之后会立即启动时间等待计时器。
计算机网络体系
应用层
会话层
表示层
传输层
网络层
数据链路层
物理层
TCP和UDP区别
传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。
Internet 协议集支持一个无连接的传输协议,该协议称为用户数据报协议(UDP,User Datagram Protocol)。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。
具体可参考 https://www.cnblogs.com/williamjie/p/9390164.html
输入网址后的全过程
1. 首先嘛,你得在浏览器里输入要网址:
2. 浏览器查找域名的IP地址
3. 浏览器给web服务器发送一个HTTP请求
4. 服务端的永久重定向响应
5. 浏览器跟踪重定向地址
6. 服务器“处理”请求
7. 服务器发回一个HTML响应
8. 浏览器开始显示HTML
//9. 浏览器发送获取嵌入在HTML中的对象
//10. 浏览器发送异步(AJAX)请求
具体可参考 https://www.cnblogs.com/linyx/p/3985160.html
访问一个页面的全过程
1.DNS解析成IP地址
2与目的主机进行TCP连接
3.发起HTTP请求
。。。
首先通过域名找到IP,如果缓存里没有就要请求DNS服务器;得到IP后开始与目的主机进行三次握手来建立TCP连接;连接建立后进行HTTP访问,传输并获取网页内容;传输完后与目的主机四次挥手来断开TCP连接。
详见https://blog.csdn.net/u012862311/article/details/78753232
http状态码
HTTP状态码(英语:HTTP Status Code)是用以表示网页服务器超文本传输协议响应状态的3位数字代码。
如404 Not found; 200 OK
1开头 消息
2 成功
3 重定向
4 请求错误
5 服务器错误
具体可参考百度百科 https://baike.baidu.com/item/HTTP状态码/5053660?fr=aladdin
500 Internal Server Error 未曾预料的错误,一般是在源代码中出错
501 | 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。 |
502 | 作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。 |
503 | 由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理500响应的方式处理它。 注意:503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。 |
504 | 作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。 注意:某些代理服务器在DNS查询超时时会返回400或者500错误 |
来自 https://mp.weixin.qq.com/s?__biz=MzA4MjkxMzMyNg==&mid=2654068952&idx=1&sn=1bd63a71610d73fcd563888d6f93398d&scene=24&srcid=0804843QrwLCsKWGYxfPum2H#wechat_redirect
301 redirect: 301 代表永久性转移(Permanently Moved)
302 redirect: 302 代表暂时性转移(Temporarily Moved )
详细来说,301和302状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。
来自 https://blog.csdn.net/ai2000ai/article/details/80242193
如果5开头,如何具体定位问题
通常我们使用WebException进行捕获
具体可参考 https://blog.csdn.net/hexieshangwang/article/details/47192689
https为什么是安全的
Https的作用
- 内容加密 建立一个信息安全通道,来保证数据传输的安全;
- 身份验证 确认网站的真实性;
- 数据完整性 防止内容被第三方冒充或者篡改
负载均衡
get和post的区别
POST和GET是HTTP请求的两种方式,都可实现将数据从浏览器向服务器发送带参数的请求。
HTTP请求底层协议都是TCP/IP,所以两者没有本质的区别。
- GET提交的数据放在URL中,POST则不会。这是最显而易见的差别。这点意味着GET更不安全(POST也不安全,因为HTTP是明文传输抓包就能获取数据内容,要想安全还得加密)
- GET回退浏览器无害,POST会再次提交请求(GET方法回退后浏览器再缓存中拿结果,POST每次都会创建新资源)
- GET提交的数据大小有限制(是因为浏览器对URL的长度有限制,GET本身没有限制),POST没有
- GET可以被保存为书签,POST不可以。这一点也能感受到。
- GET能被缓存,POST不能
- GET只允许ASCII字符,POST没有限制
- GET会保存再浏览器历史记录中,POST不会。这点也能感受到。
总之,两者之间没有本质区别,区别就在于数据存储的位置。各自有适用环境,根据需求选择合适的方法即可。
HTTP请求的组成
HTTP由四部分组成:
- 请求行(request line):用于说明请求类型、要访问的资源路径、HTTP版本号(GET /index.html HTTP/1.1)
- 请求头部(header):用于说明服务器要使用的附加信息
- 一个空行
- 请求数据(body):任意添加的数据
请求行:
①是请求方法,GET和POST是最常见的HTTP方法,除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
②为请求对应的URL地址,它和报文头的Host属性组成完整的请求URL。
③是协议名称及版本号。
请求头:
④是HTTP的报文头,报文头包含若干个属性,格式为“属性名:属性值”,服务端据此获取客户端的信息。
与缓存相关的规则信息,均包含在header中
Accept cookie Referer Cache-Control
请求体:
⑤是报文体,它将一个页面表单中的组件值通过param1=value1¶m2=value2的键值对形式编码成一个格式化串,它承载多个请求参数的数据。不但报文体可以传递请求参数,请求URL也可以通过类似于“/chapter15/user.html? param1=value1¶m2=value2”的方式传递请求参数。
详见 https://blog.csdn.net/mao_xiaoxi/article/details/89313734
HTTP的响应报文也由三部分组成(响应行+响应头+响应体)
响应行:
①报文协议及版本;
②状态码及状态描述;
响应头:
③响应报文头,也是由多个属性组成;
Cache-Control ETag Set-Cookie Location
响应体:
④响应报文体,即我们真正要的“干货”
cookie和session的区别
Session:在计算机中,尤其是在网络应用中,称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样,当用户在应用程序的Web页之间跳转时,存储在Session对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web页时,如果该用户还没有会话,则Web服务器将自动创建一个 Session对象。当会话过期或被放弃后,服务器将终止该会话。Session 对象最常见的一个用法就是存储用户的首选项。例如,如果用户指明不喜欢查看图形,就可以将该信息存储在Session对象中。
区别:1、数据存放位置不同:cookie数据存放在客户的浏览器上,session数据放在服务器上。2、安全程度不同:cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。3、性能使用程度不同:session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。4、数据存储大小不同:单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie,而session则存储与服务端,浏览器对其没有限制。
如何让UDP实现可靠传输
自定义通讯协议,在应用层定义一些可靠的协议,比如检测包的顺序,重复包等问题,如果没有收到对方的ACK,重新发包
UDP没有Delievery Garuantee,也没有顺序保证,所以如果你要求你的数据发送与接受既要高效,又要保证有序,收包确认等,你就需要在UDP协议上构建自己的协议。比如RTCP,RTP协议就是在UPD协议之上专门为H.323协议簇上的IP电话设计的一种介于传输层和应用层之间的协议。
具体详见 https://blog.csdn.net/jxm_96/article/details/53544183
断点续传
断点续传指的是在下载或上传时,将下载或上传任务(一个文件或一个压缩包)人为的划分为几个部分,每一个部分采用一个线程进行上传或下载,如果碰到网络故障,可以从已经上传或下载的部分开始继续上传下载未完成的部分,而没有必要从头开始上传下载。用户可以节省时间,提高速度。
原理
首先客户端向服务端发送一个请求(下载文件)。然后服务端响应请求,信息包含文件总大小、文件流开始和结束位置、内容大小等。那具体是怎么实现的呢?
HTTP/1.1有个头属性Range。比如你发送请求的时候带上Range:0-199
,等于你是请求0到199之间的数据。然后服务器响应请求Content-Range: bytes 0-199/250
,表示你获取了0到199之间的数据,总大小是250。(也就是告诉你还有数据没有下载完)。
详见 https://blog.csdn.net/binyao02123202/article/details/76599949
FTP及其工作原理
文件传输协议(File Transfer Protocol,FTP)是用于在网络上进行文件传输的一套标准协议,它工作在 OSI 模型的第七层, TCP 模型的第四层, 即应用层, 使用 TCP 传输而不是 UDP, 客户在和服务器建立连接前要经过一个“三次握手”的过程, 保证客户与服务器之间的连接是可靠的, 而且是面向连接, 为数据传输提供可靠保证。
FTP允许用户以文件操作的方式(如文件的增、删、改、查、传送等)与另一主机相互通信。然而, 用户并不真正登录到自己想要存取的计算机上面而成为完全用户, 可用FTP程序访问远程资源, 实现用户往返传输文件、目录管理以及访问电子邮件等等, 即使双方计算机可能配有不同的操作系统和文件存储方式。
FTP 是基于客户———服务器(C/S)模型而设计的,在客户端与 FTP 服务器之间建立两个连接。
开发任何基于 FTP 的客户端软件都必须遵循 FTP 的工作原理,FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条 TCP 连接,一条是数据连接,用于数据传送;另一条是控制连接,用于传送控制信息(命令和响应),这种将命令和数据分开传送的思想大大提高了 FTP 的效率,而其它客户服务器应用程序一般只有一条 TCP 连接。图 1 给出了 FTP 的基本模型。客户有三个构件:用户接口、客户控制进程和客户数据传送进程。服务器有两个构件:服务器控制进程和服务器数据传送进程。在整个交互的 FTP 会话中,控制连接始终是处于连接状态的,数据连接则在每一次文件传送时先打开后关闭。
控制连接 21端口 用于发送ftp命令
数据连接 20端口 用于上传下载数据
数据连接的建立类型:
1主动模式: 服务器主动发起的数据连接
首先由客户端的21 端口建立ftp控制连接 当需要传输数据时 客户端以port命令告知服务器 我打开了某端口 你过来链接我 预算服务器从20端口向该客户端该端口发送请求并建立数据连接
2被动连接模式:服务器等待数据连接
如果客户端所在的网络的防火墙禁止主动模式连接 通常会使用被动模式
首先由客户端的额21端口建立ftp控制连接 当需要传输数据时 服务器以pasv命令告知客户端 我打开了某端口 你过来连接我 于是客户端向服务端的该端口(非20) 发送请求并建立数据连接
DNS查询过程
DNS解析:域名通过DNS转化成ip地址的过程。
为什么要 DNS 解析?
因为 http 是基于 tcp 连接的,而 tcp 则是通过 ip 地址去识别访问的。DNS 解析就是域名转化成 ip 地址的过程。
查询过程
(以下各步骤中,找到目标地址即返回,找不到会执行下一步)
- 先去本地 hosts 中找对应地址
- 再去域名解析器(缓存)中寻找映射关系
- 找 DNS 服务器问是不是配置在其下的
- DNS 服务器有没有缓存它的映射关系
- DNS 根据配置去找到根服务器或者上一级 DNS 服务器
- …
来自 https://www.jianshu.com/p/6ed368751fb2
DNS 的查询有两种方式。一般两种方式都会用到。递归查询是用在本地机查询本地 DNS 服务器的过程,迭代查询是本地 DNS 服务器在互联网上查找目标机的过程。
-
a -> b 这个链路就是递归查询,因为 b 帮助了 a 进行查询。
-
b => C, b => D,这个就是迭代查询,因为 C 没有帮 b 去查,而是直接给了他一个地址去让它再去打听。
域名解析是页面加载的第一步,那么域名是如何解析的呢?以Chrome为例:
1.Chrome浏览器 会首先搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存),看自身的缓存中是否有www.linux178.com 对应的条目,而且没有过期,如果有且没有过期则解析到此结束。
2.如果浏览器自身的缓存里面没有找到对应的条目,那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.
3.如果在Windows系统的DNS缓存也没有找到,那么尝试读取hosts文件(位于C:WindowsSystem32driversetc),看看这里面有没有该域名对应的IP地址,如果有则解析成功。
4.如果在hosts文件中也没有找到对应的条目,浏览器就会发起一个DNS的系统调用,就会向本地配置的首选DNS服务器(一般是电信运营商提供的,也可以使用像Google提供的DNS服务器)发起域名解析请求(通过的是UDP协议向DNS的53端口发起请求,这个请求是递归的请求,也就是运营商的DNS服务器必须得提供给我们该域名的IP地址),运营商的DNS服务器首先查找自身的缓存,找到对应的条目,且没有过期,则解析成功。
如果没有找到对应的条目,则有运营商的DNS代我们的浏览器发起迭代DNS解析请求,它首先是会找根域的DNS的IP地址(这个DNS服务器都内置13台根域的DNS的IP地址),找打根域的DNS地址,就会向其发起请求(请问www.linux178.com这个域名的IP地址是多少啊?),根域发现这是一个顶级域com域的一个域名,于是就告诉运营商的DNS我不知道这个域名的IP地址,但是我知道com域的IP地址,你去找它去,于是运营商的DNS就得到了com域的IP地址,又向com域的IP地址发起了请求(请问www.linux178.com这个域名的IP地址是多少?),com域这台服务器告诉运营商的DNS我不知道www.linux178.com这个域名的IP地址,但是我知道linux178.com这个域的DNS地址,你去找它去,于是运营商的DNS又向linux178.com这个域名的DNS地址(这个一般就是由域名注册商提供的,像万网,新网等)发起请求(请问www.linux178.com这个域名的IP地址是多少?),这个时候linux178.com域的DNS服务器一查,诶,果真在我这里,于是就把找到的结果发送给运营商的DNS服务器,这个时候运营商的DNS服务器就拿到了www.linux178.com这个域名对应的IP地址,并返回给Windows系统内核,内核又把结果返回给浏览器,终于浏览器拿到了www.linux178.com对应的IP地址,该进行一步的动作了。
来自 https://blog.csdn.net/u014465934/article/details/83241097
TCP协议保证数据传输可靠性的方式主要有:
(校序重流拥)
校验和
发送的数据包的二进制相加然后取反,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段。
确认应答+序列号
TCP给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
超时重传
当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
流量控制
TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。
接收方有即时窗口(滑动窗口),随ACK报文发送
拥塞控制
当网络拥塞时,减少数据的发送。
发送方有拥塞窗口,发送数据前比对接收方发过来的即使窗口,取小
慢启动、拥塞避免、拥塞发送、快速恢复
应用数据被分割成TCP认为最适合发送的数据块。
TCP的接收端会丢弃重复的数据。
来自 https://blog.csdn.net/cbjcry/article/details/84925028
长连接和短连接
在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头加入这行代码:
Connection:keep-alive
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
来自https://www.cnblogs.com/gotodsp/p/6366163.html