Web前端最新剑指Offer——知识点储备-网络基础_剑指offer 网络，前端程序设计基础

2401_84618926

已于 2024-05-09 07:13:11 修改

阅读量1k

点赞数 24

分类专栏：程序员文章标签：前端网络

于 2024-05-09 07:13:09 首次发布

本文链接：https://blog.csdn.net/2401_84618926/article/details/138595175

版权

程序员专栏收录该内容

103 篇文章 0 订阅

订阅专栏

计算机网络

HTTP 缓存
你知道 302 状态码是什么嘛？你平时浏览网页的过程中遇到过哪些 302 的场景？
HTTP 常用的请求方式，区别和用途？
HTTPS 是什么？具体流程
三次握手和四次挥手
你对 TCP 滑动窗口有了解嘛？
WebSocket与Ajax的区别
了解 WebSocket 嘛？
HTTP 如何实现长连接？在什么时候会超时？
TCP 如何保证有效传输及拥塞控制原理。
TCP 协议怎么保证可靠的，UDP 为什么不可靠？

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

算法

链表
字符串
数组问题
二叉树
排序算法
二分查找
动态规划
BFS
栈
DFS
回溯算法

http是超文本传输协议，信息是明文传输，https则是具有安全性的SSL加密传输协议;
http和https使用的是完全不同的链接方式，所用的端口也不一样，前者是80，后者是443;
http的链接很简单，是无状态的。

二、从输入网址到获得网页的过程

查询DNS,获取域名对应的ip地址；
浏览器搜索自身的DNS缓存；
搜索操作系统的DNS缓存；
读取本地的HOST文件；
发起一个DNS系统调用；
宽带运营服务器查看本身缓存；
运营商服务器发起一个迭代DNS解析请求；
浏览器获得域名对应的ip地址后，发起HTTP三次握手；
TCP/IP链接建立起来后，浏览器就可以向服务器发送HTTP请求;
服务器接收到这个请求，根据路径参数，经过后端的一些处理生成html页面代码返回给浏览器;
浏览器拿到完整的html页面代码开始解析和渲染，如果遇到引用外部的js,css，图片等静态资源，它们同样也是一个个的http请求，都需要经过上面的步骤。

三、TCP如何保证可靠传输？三次握手过程？四次挥手过程？

3.1 TCP如何保证可靠传输

数据报校验;
超时重传机制;
应答机制;
对失序数据包重排序;
TCP还能提供流量控制;

TCP是什么：
是一种面向连接、可靠、基于字节流的传输层通信协议。

TCP的组成部分：
特别要注意的信息：

ACK：TCP协议规定，只有ACK=1时有效，也就是连接建立后所有发送的报文ACK必须为1;
SYN：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。若对方同意建立连接，则响应的报文中使SYN=1和ACK=1.（SYN置1表示这是一个连接请求或连接接受报文）
FIN(finish)：表示终结的意思，用来释放一个连接。当FIN=1时，表明此报文段的发送数据已经发送完毕，并要求释放连接。
序号：占4字节，范围（0，232-1）,共232个序号。序号增加到232-1后，下一个序号就又回到0（采用取模运算）。TCP是面向字节流的，传输的字节流每一个字节都按照顺序编号，且必须在连接建立时设置，首部中的序号字段指本报文段所发送的数据第一个字节的序号。

例如：一报文段的序号字段值是301，而携带的数据共有100字节，表明第一个字节序号是301，最后一个字节序号是400.下一个报文段的数据序号从401开始，这个301、401叫做报文段序号。

3.2 三次握手的过程

这里写图片描述

第一次握手：首先由Client发出请求连接即SYN=1，ACK=0(TCP规定SYN=1时不能携带数据，但要消耗一个序列号)，因此声明自己的序号是seq=x;
第二次握手：然后Server一直监听客户端是否发来请求，监听到客户端有请求发送，核对后进行回复确认，即SYN=1，ACK=1，seq=y, ack=x+1;
第三次握手：然后Client再依次进行确认，但不用SYN,这时即为ACK=1，seq=x+1, ack=y+1. 然后就建立连接;
问题：为什么进行三次握手，两次确认，两次握手，一次确认不行么？
问题的根源在于防止已失效的链接请求报文段又传送到server，产生错误。

四、什么是“已失效的链接请求报文段”

考虑一种正常的情况:A发出链接请求，但因链接请求报文丢失而未收到确认（可能网络阻塞、断网、断电等）。于是A再重传一次链接请求，后来收到确认（网络环境变好了），建立了链接。数据传输完毕后，就释放了链接。A共发送两个链接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的链接请求。

现假定一种异常情况，A发送的第一个链接请求报文段并没有丢失，而在某些网络结点长时间滞留，以致延误到链接释放以后的某个时间才到达B。本来这是一个早已失效的报文段，但B收到此失效的链接请求报文段后，就误认为是A又发出一次新的链接请求。于是向A发出确认报文段，同意建立连接。假设不采用三次握手，那么只要B发出确认，新的链接就建立。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输链接已经建立了，并一直等待A发来数据。从而造成B的许多资源白白浪费。

采用三次握手的办法就可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认，B由于收不到确认，就知道A并没有要求建立连接。

释放连接的过程：
这里写图片描述
要理解四次挥手的过程，客户端A没有东西发送时，就会请求释放连接，发送一个FIN包（没有数据），此时客户端状态变成FIN_WAIT_1(A不能发数据，但可以接受数据)，服务端B接受到A那边的链接已经关闭。B会发送一个确认的包ACK,A收到B的确认后进入FIN_WAIT_2等待状态，等待B释放连接，此时B把要发的数据发给A，发完并向A请求释放连接FIN=1，A收到后回复一个确认消息ACK=1，并进入Time_wait状态，等待2msl.