[{"_1":2,"_1023":-5,"_1024":-5},"loaderData",{"_3":4,"_53":54},"root",{"_5":6},"clerkState",{"_7":8},"__internal_clerk_state",{"_9":10,"_25":26,"_27":28,"_29":28,"_30":24,"_31":28,"_32":28,"_33":28,"_34":28,"_35":28,"_36":28,"_37":28,"_38":28,"_39":40,"_49":28,"_50":28,"_51":24,"_52":24},"__clerk_ssr_state",{"_11":12,"_13":-5,"_14":-5,"_15":-5,"_16":-5,"_17":-5,"_18":-5,"_19":-5,"_20":-5,"_21":-5,"_22":-5,"_23":24},"tokenType","session_token","sessionClaims","sessionId","sessionStatus","userId","actor","orgId","orgRole","orgSlug","orgPermissions","factorVerificationAge","isAuthenticated",false,"__publishableKey","pk_live_Y2xlcmsucXVlc3Rpb25zLnZpc3VhbGl6ZWl0LmFwcCQ","__proxyUrl","","__domain","__isSatellite","__signInUrl","__signUpUrl","__afterSignInUrl","__afterSignUpUrl","__signInForceRedirectUrl","__signUpForceRedirectUrl","__signInFallbackRedirectUrl","__signUpFallbackRedirectUrl","__clerk_debug",{"_41":24,"_23":24,"_42":28,"_43":44,"_45":28,"_46":26,"_47":24,"_48":28},"isSignedIn","proxyUrl","reason","session-token-and-uat-missing","message","publishableKey","isSatellite","domain","__clerkJSUrl","__clerkJSVersion","__telemetryDisabled","__telemetryDebug","routes/_index",{"_55":56,"_1019":1020},"questions",[57,196,236,275,300,325,354,382,407,436,461,490,519,548,573,598,623,648,673,698,723,748,773,797,821,845,869,894,919,944,969,994],{"_58":59,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":75,"_76":77,"_78":79,"_111":112,"_131":132,"_133":24,"_134":-5,"_135":136,"_137":138,"_159":152,"_153":160,"_155":161,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":166,"_170":171,"_176":177,"_178":179,"_190":191,"_192":-5,"_193":-5,"_194":195},"url","https://api.github.com/repos/pro-collection/interview-question/issues/572","repository_url","https://api.github.com/repos/pro-collection/interview-question","labels_url","https://api.github.com/repos/pro-collection/interview-question/issues/572/labels{/name}","comments_url","https://api.github.com/repos/pro-collection/interview-question/issues/572/comments","events_url","https://api.github.com/repos/pro-collection/interview-question/issues/572/events","html_url","https://github.com/pro-collection/interview-question/issues/572","id",1920641960,"node_id","I_kwDOJGDC6c5yequo","number",572,"title","如何拦截 web 应用的请求【热度: 487】","user",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"login","yanlele",22188674,"MDQ6VXNlcjIyMTg4Njc0","avatar_url","https://avatars.githubusercontent.com/u/22188674?v=4","gravatar_id","https://api.github.com/users/yanlele","https://github.com/yanlele","followers_url","https://api.github.com/users/yanlele/followers","following_url","https://api.github.com/users/yanlele/following{/other_user}","gists_url","https://api.github.com/users/yanlele/gists{/gist_id}","starred_url","https://api.github.com/users/yanlele/starred{/owner}{/repo}","subscriptions_url","https://api.github.com/users/yanlele/subscriptions","organizations_url","https://api.github.com/users/yanlele/orgs","repos_url","https://api.github.com/users/yanlele/repos","https://api.github.com/users/yanlele/events{/privacy}","received_events_url","https://api.github.com/users/yanlele/received_events","type","User","user_view_type","public","site_admin","labels",[113,124],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},5232529101,"LA_kwDOJGDC6c8AAAABN-IOzQ","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BD%91%E7%BB%9C","name","网络","color","1A8829","default","description","web 网络相关",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},5597058003,"LA_kwDOJGDC6c8AAAABTZxT0w","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%BF%AB%E6%89%8B","快手","ededed","公司标签","state","open","locked","assignee","assignees",[],"milestone",{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":148,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/3","https://github.com/pro-collection/interview-question/milestone/3","https://api.github.com/repos/pro-collection/interview-question/milestones/3/labels",9124547,"MI_kwDOJGDC6c4AizrD",3,"高","高级别面试问题","creator",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"open_issues",454,"closed_issues",0,"created_at","2023-03-06T15:00:27Z","updated_at","2025-09-07T06:21:17Z","due_on","closed_at","comments","2023-10-01T08:33:19Z","2023-10-01T08:34:35Z","author_association","MEMBER","active_lock_reason","sub_issues_summary",{"_167":152,"_168":152,"_169":152},"total","completed","percent_completed","issue_dependencies_summary",{"_172":152,"_173":152,"_174":152,"_175":152},"blocked_by","total_blocked_by","blocking","total_blocking","body","**关键词**：web前端监听请求、前端拦截请求\r\n\r\n在前端拦截和处理 Web 应用的所有请求，可以使用以下方法：\r\n\r\n\r\n1. **使用 Fetch 或 XMLHttpRequest**：在前端代码中使用 Fetch API 或 XMLHttpRequest 对象发送请求。通过拦截 Fetch 或 XMLHttpRequest 对象的 open 和 send 方法，可以在请求发出前进行拦截和修改。这样可以捕获请求的相关信息，并进行相应的处理。\r\n\r\n示例代码（使用 Fetch API）：\r\n\r\n```javascript\r\nconst originalFetch = window.fetch;\r\nwindow.fetch = function (url, options) {\r\n // 在请求发出前进行拦截和处理\r\n console.log('拦截到请求:', url);\r\n \r\n // 可以修改请求的相关信息\r\n // options.headers['Authorization'] = 'Bearer token';\r\n \r\n return originalFetch.apply(this, arguments);\r\n};\r\n```\r\n\r\n\r\n2. **使用 Service Worker：Service Worker** 是一种在浏览器背后运行的脚本，可以拦截和处理网络请求。通过注册一个 Service Worker，可以在其中监听和处理请求事件。从而实现拦截和处理 Web 应用的所有请求。\r\n\r\n示例代码：\r\n\r\n```javascript\r\nself.addEventListener('fetch', function(event) {\r\n // 在请求发出前进行拦截和处理\r\n console.log('拦截到请求:', event.request.url);\r\n \r\n // 可以修改请求的相关信息\r\n // event.request.headers.set('Authorization', 'Bearer token');\r\n \r\n event.respondWith(fetch(event.request));\r\n});\r\n```\r\n\r\n需要注意的是，前端拦截和处理请求只能在客户端进行，对于服务器端的请求无法拦截。此外，拦截和处理请求可能会对性能产生一定的影响，因此要根据实际情况进行权衡和调优。同时，对于一些敏感信息（如密码、个人信息等），应该谨慎处理，确保安全性。\r\n\r\n\r\n3. **如果是使用是三方请求库，比如 aixos** ，可以直接使用三方库提供的能力\r\n\r\n是的，使用 axios 也可以拦截请求。axios 提供了拦截器（interceptors）的功能，可以在请求发出前进行拦截和处理。\r\n\r\n示例代码：\r\n\r\n```javascript\r\nimport axios from 'axios';\r\n\r\n// 请求拦截器\r\naxios.interceptors.request.use(function (config) {\r\n // 在请求发出前进行拦截和处理\r\n console.log('拦截到请求:', config.url);\r\n \r\n // 可以修改请求的相关信息\r\n // config.headers['Authorization'] = 'Bearer token';\r\n \r\n return config;\r\n}, function (error) {\r\n return Promise.reject(error);\r\n});\r\n\r\n// 发送请求\r\naxios.get('/api/data')\r\n .then(function (response) {\r\n console.log(response.data);\r\n })\r\n .catch(function (error) {\r\n console.error(error);\r\n });\r\n```\r\n在上述代码中，通过使用 `interceptors.request` 方法，可以对请求进行拦截和处理。在拦截器函数中，可以修改请求的相关信息，并返回修改后的配置对象。\r\n\r\n使用 axios 拦截请求只能在客户端进行，对服务器端的请求无法拦截。同样需要谨慎处理敏感信息，并确保安全性。\r\n","reactions",{"_58":180,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/572/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/572/timeline","performed_via_github_app","state_reason","score",1,{"_58":197,"_60":61,"_62":198,"_64":199,"_66":200,"_68":201,"_70":202,"_72":203,"_74":204,"_76":205,"_78":206,"_111":207,"_131":132,"_133":24,"_134":-5,"_135":214,"_137":215,"_159":195,"_153":228,"_155":229,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":230,"_170":231,"_176":232,"_178":233,"_190":235,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/566","https://api.github.com/repos/pro-collection/interview-question/issues/566/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/566/comments","https://api.github.com/repos/pro-collection/interview-question/issues/566/events","https://github.com/pro-collection/interview-question/issues/566",1910283387,"I_kwDOJGDC6c5x3Jx7",566,"https 如何保证安全的？【热度: 782】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[208,209],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":210,"_72":211,"_58":212,"_117":213,"_119":129,"_121":24,"_122":130},5312214934,"LA_kwDOJGDC6c8AAAABPKH3lg","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BD%91%E6%98%93","网易",[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":224,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/2","https://github.com/pro-collection/interview-question/milestone/2","https://api.github.com/repos/pro-collection/interview-question/milestones/2/labels",9124545,"MI_kwDOJGDC6c4AizrB",2,"中","中级程序面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},510,"2023-03-06T15:00:15Z","2025-09-07T06:08:31Z","2023-09-24T16:00:12Z","2023-09-24T16:01:39Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：https 安全性\r\n\r\nHTTPS相比HTTP更安全的原因主要有以下几点：\r\n\r\n1. 数据传输加密：HTTPS使用SSL/TLS协议对数据进行加密传输，通过使用对称密钥加密传输数据，并使用非对称密钥进行身份验证和密钥交换。这意味着即使攻击者截获了数据包，也无法解密其中的内容。\r\n\r\n2. 身份验证和数据完整性：HTTPS使用数字证书对网站进行身份验证，确保用户连接的是正确的网站。同时，数字证书也用于确保数据的完整性，以防止数据在传输过程中被篡改。\r\n\r\n3. 防止中间人攻击：HTTPS通过使用公钥加密和数字签名等技术，可以防止中间人攻击。中间人攻击是指攻击者在用户与服务器之间插入自己的恶意代理，在两者之间进行通信并窃取敏感信息。\r\n\r\n4. HTTP头隐私保护：HTTPS可以提供对HTTP头信息的隐私保护，防止攻击者通过分析HTTP头信息获取用户的敏感信息。\r\n\r\nHTTPS通过数据加密、身份验证和数据完整性保护等机制，提供了更高的安全性，能够有效防止数据被窃取、篡改和中间人攻击等风险。相比之下，HTTP是明文传输，不具备这些安全保护机制。因此，对于需要保护用户隐私和防止数据被攻击的网站，使用HTTPS是更安全的选择。\r\n\r\n",{"_58":234,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/566/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/566/timeline",{"_58":237,"_60":61,"_62":238,"_64":239,"_66":240,"_68":241,"_70":242,"_72":243,"_74":244,"_76":245,"_78":246,"_111":247,"_131":132,"_133":24,"_134":-5,"_135":254,"_137":255,"_159":152,"_153":267,"_155":268,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":269,"_170":270,"_176":271,"_178":272,"_190":274,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/536","https://api.github.com/repos/pro-collection/interview-question/issues/536/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/536/comments","https://api.github.com/repos/pro-collection/interview-question/issues/536/events","https://github.com/pro-collection/interview-question/issues/536",1867239393,"I_kwDOJGDC6c5vS8_h",536,"http 请求中 GET 和 POST 有什么区别【热度: 505】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[248,249],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":250,"_72":251,"_58":252,"_117":253,"_119":129,"_121":24,"_122":130},5562711972,"LA_kwDOJGDC6c8AAAABS5A_pA","https://api.github.com/repos/pro-collection/interview-question/labels/Shopee","Shopee",[],{"_58":256,"_68":257,"_62":258,"_70":259,"_72":260,"_74":195,"_76":261,"_122":262,"_147":263,"_149":264,"_151":152,"_131":132,"_153":265,"_155":266,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/1","https://github.com/pro-collection/interview-question/milestone/1","https://api.github.com/repos/pro-collection/interview-question/milestones/1/labels",9124541,"MI_kwDOJGDC6c4Aizq9","初","初级面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},79,"2023-03-06T14:59:51Z","2024-11-22T14:22:55Z","2023-08-25T15:19:00Z","2023-08-25T15:19:01Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：GET 和 POST 区别\n\n| | GET请求 | POST请求 |\n| --- | --------------------------------------------------------- | --------------------------------------------------------- |\n| 参数传递方式 | 参数通过URL的查询字符串传递，例如：http://example.com/api?param1=value1¶m2=value2 | 参数通过请求体传递，不会暴露在URL中 |\n| 参数长度限制 | 有长度限制，不适合传输大量数据 | 没有长度限制，适合传输大量数据 |\n| URL暴露 | 参数会被附加在URL中，可以通过浏览器地址栏直接访问 | 参数不会显示在浏览器地址栏中 |\n| 缓存 | 会被浏览器缓存 | 不会被浏览器缓存 |\n| 副作用 | 不具有副作用，只是获取数据 | 具有副作用，可以对服务器数据进行修改、新增或删除操作 |\n| 适用场景 | 获取数据 | 提交表单数据 |\n| | 在URL中传递少量参数 | 传输大量数据 |\n| | 缓存数据 | 修改、新增或删除数据 |\n| | | 不希望数据暴露在URL中 |\n",{"_58":273,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/536/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/536/timeline",{"_58":276,"_60":61,"_62":277,"_64":278,"_66":279,"_68":280,"_70":281,"_72":282,"_74":283,"_76":284,"_78":285,"_111":286,"_131":132,"_133":24,"_134":-5,"_135":289,"_137":290,"_159":152,"_153":292,"_155":293,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":294,"_170":295,"_176":296,"_178":297,"_190":299,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/535","https://api.github.com/repos/pro-collection/interview-question/issues/535/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/535/comments","https://api.github.com/repos/pro-collection/interview-question/issues/535/events","https://github.com/pro-collection/interview-question/issues/535",1867233833,"I_kwDOJGDC6c5vS7op",535,"如何实现大文件断点续传【热度: 897】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[287,288],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":210,"_72":211,"_58":212,"_117":213,"_119":129,"_121":24,"_122":130},[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":291,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-25T15:15:00Z","2023-08-25T15:15:26Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：文件上传断点续传\n\n前端实现断点续传一般涉及到以下几个步骤：\n\n1. 分片上传：将大文件分割成多个小的文件块。可以使用 JavaScript 的 `File` 对象的 `slice` 方法来实现分片。\n\n2. 上传文件块：使用 XMLHttpRequest 或 Fetch API 发送每个文件块到服务器。可以将每个文件块的索引、总文件大小等信息一同发送到服务器。\n\n3. 保存上传进度：在每个文件块上传成功后，可以将已上传的块数、已上传的字节数等信息保存到本地，以便在继续上传时恢复进度。\n\n4. 续传：在继续上传时，先从本地恢复已上传的进度信息。然后根据已上传的字节数，计算出下一个文件块的起始位置，然后继续上传剩余的文件块。\n\n5. 合并文件块：在所有文件块都上传完成后，服务器可以将这些文件块合并为完整的文件。可以通过将所有文件块的内容拼接在一起或使用服务器端的工具进行合并。\n\n需要注意的是，断点续传的实现还需要服务器端的支持。服务器端需要接收和处理分片上传的请求，并保存和管理已上传的文件块，以便在续传时恢复文件的完整性。因此，前端实现断点续传需要和后端进行协作。\n",{"_58":298,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/535/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/535/timeline",{"_58":301,"_60":61,"_62":302,"_64":303,"_66":304,"_68":305,"_70":306,"_72":307,"_74":308,"_76":309,"_78":310,"_111":311,"_131":132,"_133":24,"_134":-5,"_135":314,"_137":315,"_159":152,"_153":317,"_155":318,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":319,"_170":320,"_176":321,"_178":322,"_190":324,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/534","https://api.github.com/repos/pro-collection/interview-question/issues/534/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/534/comments","https://api.github.com/repos/pro-collection/interview-question/issues/534/events","https://github.com/pro-collection/interview-question/issues/534",1867227476,"I_kwDOJGDC6c5vS6FU",534,"长连接了解多少【热度: 567】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[312,313],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":210,"_72":211,"_58":212,"_117":213,"_119":129,"_121":24,"_122":130},[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":316,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-25T15:10:41Z","2023-08-25T15:10:56Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：http 长连接过程\n\nHTTP/1.1 的长连接（Keep-Alive）是一种机制，使客户端和服务器在同一连接上可以发送和接收多个 HTTP 请求和响应。它的原理如下：\n\n1. 客户端发送请求：当客户端发起一个 HTTP 请求时，在请求头中会包含一个 `Connection` 字段，标识这个连接是否需要保持持久连接。如果客户端希望保持连接，它会将该字段设置为 `keep-alive`。\n\n2. 服务器响应：当服务器收到客户端的请求后，如果它支持长连接，它会在响应头中添加一个 `Connection` 字段，也设置为 `keep-alive`，表示服务器同意保持连接。\n\n3. 客户端发送下一个请求：在客户端收到服务器的响应后，如果它也同意保持连接，客户端可以继续发送下一个请求。这个请求会被发送到同一连接上，而不是创建一个新的连接。\n\n4. 保持连接或关闭连接：客户端和服务器可以在多个请求和响应之间重复步骤 3。当一方决定不再继续发送请求时，它可以在请求头或响应头中将 `Connection` 字段设置为 `close`，表示关闭连接。\n\n长连接的原理是通过减少连接的建立和关闭次数，来提高性能和效率。它可以减少网络延迟和连接建立的开销，从而加快请求和响应的传输速度。同时，长连接还可以减少服务器的负载，因为服务器不需要频繁地处理连接的建立和关闭。\n\n需要注意的是，尽管 HTTP/1.1 支持长连接，但它并不是默认启用的，需要在请求头中明确指定 `Connection: keep-alive` 才能使用长连接。此外，服务器也可以在响应头中明确指定长连接。如果客户端和服务器都支持长连接，并在请求和响应中都明确设置了长连接，那么连接就会被保持，直到其中一方关闭连接或指定关闭。\n",{"_58":323,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/534/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/534/timeline",{"_58":326,"_60":61,"_62":327,"_64":328,"_66":329,"_68":330,"_70":331,"_72":332,"_74":333,"_76":334,"_78":335,"_111":336,"_131":132,"_133":24,"_134":-5,"_135":343,"_137":344,"_159":152,"_153":346,"_155":347,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":348,"_170":349,"_176":350,"_178":351,"_190":353,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/532","https://api.github.com/repos/pro-collection/interview-question/issues/532/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/532/comments","https://api.github.com/repos/pro-collection/interview-question/issues/532/events","https://github.com/pro-collection/interview-question/issues/532",1867192918,"I_kwDOJGDC6c5vSxpW",532,"什么是 JWT【热度: 428】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[337,338],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":339,"_72":340,"_58":341,"_117":342,"_119":129,"_121":24,"_122":130},5326133419,"LA_kwDOJGDC6c8AAAABPXZYqw","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B0%8F%E7%B1%B3","小米",[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":345,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-25T14:47:51Z","2023-08-25T14:48:04Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：jwt 基本概念\n\nJWT是JSON Web Token的缩写，是一种用于在不同系统之间安全传输信息的开放标准。JWT通常用于身份验证和授权，它由三部分组成：头部（header）、载荷（payload）和签名（signature）。\n\n头部包含了关于令牌的元数据和算法信息，通常包括令牌的类型（例如JWT）、使用的加密算法（例如HMAC SHA256或RSA）等。\n\n载荷包含了要传输的数据，可以是用户的身份信息、权限、角色等。载荷可以自定义，但常见的标准字段有iss（令牌的签发者）、exp（令牌的过期时间）、sub（令牌的主题）等。\n\n签名是使用头部和载荷中的数据以及秘密密钥生成的，用于验证令牌的真实性和完整性。接收方可以使用相同的密钥对收到的令牌进行验证。\n\nJWT的优点包括可扩展性、易于使用和跨平台支持，它可以在各种语言和框架中使用。由于JWT是基于标准的JSON格式，因此它易于解析和处理。\n",{"_58":352,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/532/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/532/timeline",{"_58":355,"_60":61,"_62":356,"_64":357,"_66":358,"_68":359,"_70":360,"_72":361,"_74":362,"_76":363,"_78":364,"_111":365,"_131":132,"_133":24,"_134":-5,"_135":372,"_137":373,"_159":152,"_153":375,"_155":375,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":376,"_170":377,"_176":378,"_178":379,"_190":381,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/531","https://api.github.com/repos/pro-collection/interview-question/issues/531/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/531/comments","https://api.github.com/repos/pro-collection/interview-question/issues/531/events","https://github.com/pro-collection/interview-question/issues/531",1867182204,"I_kwDOJGDC6c5vSvB8",531,"Http 状态码 301 和 302 的应用场景分别是什么",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[366,367],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":368,"_72":369,"_58":370,"_117":371,"_119":129,"_121":24,"_122":130},5312738037,"LA_kwDOJGDC6c8AAAABPKny9Q","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%99%BE%E5%BA%A6","百度",[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":374,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-25T14:42:25Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"HTTP状态码301和302都是重定向状态码，用于将客户端请求重定向到另一个URL。\n\n- `301（Moved Permanently）`：表示请求的资源已永久移动到新位置。服务器发送301状态码时，还会在响应头中包含一个Location字段，指示新的资源位置。客户端接收到301响应后，会自动重定向到新的URL，并且搜索引擎也会更新索引将原来的URL替换为新的URL。301常见的应用场景包括网站改版、域名更换等需要永久重定向的情况。\n\n- `302（Found）`：表示请求的资源临时移动到不同的位置。与301不同，302状态码表示请求的资源只是暂时移动，将来可能还会回到原来的位置。服务器发送302状态码时，同样会在响应头中包含一个Location字段，指示暂时移动的位置。客户端接收到302响应后，也会自动重定向到新的URL，但搜索引擎通常不会更新索引，而是继续保留原来的URL。302常见的应用场景包括临时的维护页面、流量调度等需要临时重定向的情况。\n\n**总结**\n\n- HTTP状态码301是永久重定向，表示请求的资源已永久移动到新位置，客户端会自动重定向到新的URL，搜索引擎会更新索引。\n- HTTP状态码302是临时重定向，表示请求的资源暂时移动到不同的位置，客户端会自动重定向到新的URL，但搜索引擎会保留原来的索引。\n- 301适用于网站改版、域名更换等需要永久重定向的情况。\n- 302适用于临时的维护页面、流量调度等需要临时重定向的情况。\n\n",{"_58":380,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/531/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/531/timeline",{"_58":383,"_60":61,"_62":384,"_64":385,"_66":386,"_68":387,"_70":388,"_72":389,"_74":390,"_76":391,"_78":392,"_111":393,"_131":132,"_133":24,"_134":-5,"_135":396,"_137":397,"_159":152,"_153":399,"_155":400,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":401,"_170":402,"_176":403,"_178":404,"_190":406,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/530","https://api.github.com/repos/pro-collection/interview-question/issues/530/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/530/comments","https://api.github.com/repos/pro-collection/interview-question/issues/530/events","https://github.com/pro-collection/interview-question/issues/530",1867164707,"I_kwDOJGDC6c5vSqwj",530,"http 常见状态码有哪些【热度: 1,410】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[394,395],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":368,"_72":369,"_58":370,"_117":371,"_119":129,"_121":24,"_122":130},[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":398,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-25T14:30:59Z","2023-08-25T14:31:00Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：http常见状态码\n\nHTTP（超文本传输协议）中常见的状态码包括：\n\n1xx（信息性状态码）：表示请求已被接收并正在处理。\n\n- 100（Continue）：请求已接收，客户端应继续发送请求的剩余部分。\n- 101（Switching Protocols）：服务器要求客户端切换协议。\n\n2xx（成功状态码）：表示请求已成功处理。\n\n- 200（OK）：请求成功。\n- 201（Created）：请求已成功并创建新的资源。\n- 202（Accepted）：请求已接受，但尚未处理完成。\n- 204（No Content）：服务器已成功处理请求，但无返回内容。\n\n3xx（重定向状态码）：表示需要进一步操作才能完成请求。\n\n- 301（Moved Permanently）：请求的资源已永久移动到新位置。\n- 302（Found）：请求的资源临时移动到不同的位置。\n- 304（Not Modified）：资源未被修改，可使用缓存版本。\n\n4xx（客户端错误状态码）：表示客户端发生错误。\n\n- 400（Bad Request）：无效的请求。\n- 401（Unauthorized）：请求需要身份验证或凭证无效。\n- 403（Forbidden）：服务器拒绝请求。\n- 404（Not Found）：请求的资源不存在。\n\n5xx（服务器错误状态码）：表示服务器发生错误。\n\n- 500（Internal Server Error）：服务器遇到了错误，无法完成请求。\n- 502（Bad Gateway）：服务器作为网关或代理，从上游服务器收到无效响应。\n- 503（Service Unavailable）：服务器无法处理请求，通常是因为过载或停机维护。\n\n以上是常见的 HTTP 状态码，每个状态码都有特定的含义，用于指示请求的处理结果。\n",{"_58":405,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/530/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/530/timeline",{"_58":408,"_60":61,"_62":409,"_64":410,"_66":411,"_68":412,"_70":413,"_72":414,"_74":415,"_76":416,"_78":417,"_111":418,"_131":132,"_133":24,"_134":-5,"_135":425,"_137":426,"_159":152,"_153":428,"_155":429,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":430,"_170":431,"_176":432,"_178":433,"_190":435,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/529","https://api.github.com/repos/pro-collection/interview-question/issues/529/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/529/comments","https://api.github.com/repos/pro-collection/interview-question/issues/529/events","https://github.com/pro-collection/interview-question/issues/529",1861850103,"I_kwDOJGDC6c5u-ZP3",529,"http2 多路复用是什么, 原理是什么【热度: 353】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[419,420],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":421,"_72":422,"_58":423,"_117":424,"_119":129,"_121":24,"_122":130},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":427,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-22T16:51:09Z","2023-08-22T16:51:22Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：http2多路复用、http2多路复用原理、http2帧和流、http2流的优先级、http2头部压缩\n\n多路复用是指在HTTP/2中，多个请求/响应可以同时在同一个TCP连接上进行传输和处理的机制。\n\n在HTTP/1.1中，每个请求都需要建立一个独立的TCP连接，导致连接的建立和关闭开销很大。而在HTTP/2中，多个请求可以通过同一个TCP连接同时进行，避免了建立和关闭连接的开销。\n\n多路复用的实现原理主要包括以下几个方面：\n\n1. **帧和流**：在HTTP/2中，通信的最小单位是帧（frames），每个帧包含了一个特定类型的数据，例如请求头、响应头、请求体、响应体等。帧属于一个或多个流（stream），每个流都有唯一的标识符。多个流可以同时在同一个TCP连接上进行传输。\n\n2. **流的优先级**：在HTTP/2中，每个流都可以设置优先级，用于指定处理请求的顺序。服务器可以根据流的优先级来决定响应的优先级，从而更好地利用带宽资源。\n\n3. **头部压缩**：为了减少头部信息的传输开销，HTTP/2使用了一种称为HPACK的压缩算法。HPACK对头部信息进行压缩，并在通信双方之间维护一个共享的头部表，用于存储已经发送或接收过的头部信息。这样就可以减少重复的头部信息传输，提高传输效率。\n\n通过上述机制，HTTP/2实现了多路复用。多个请求/响应可以同时在同一个TCP连接上进行传输，提高了传输效率，减少了连接建立和关闭的开销。\n",{"_58":434,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/529/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/529/timeline",{"_58":437,"_60":61,"_62":438,"_64":439,"_66":440,"_68":441,"_70":442,"_72":443,"_74":444,"_76":445,"_78":446,"_111":447,"_131":132,"_133":24,"_134":-5,"_135":450,"_137":451,"_159":152,"_153":453,"_155":454,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":455,"_170":456,"_176":457,"_178":458,"_190":460,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/528","https://api.github.com/repos/pro-collection/interview-question/issues/528/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/528/comments","https://api.github.com/repos/pro-collection/interview-question/issues/528/events","https://github.com/pro-collection/interview-question/issues/528",1861835830,"I_kwDOJGDC6c5u-Vw2",528,"HTTP/1.0、HTTP/1.1、HTTP/2和HTTP/3之间的主要区别【热度: 1,447】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[448,449],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":421,"_72":422,"_58":423,"_117":424,"_119":129,"_121":24,"_122":130},[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":452,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-22T16:40:50Z","2023-08-22T16:41:19Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：HTTP各版本之间区别\r\n\r\n下面是一个表格，展示了HTTP/1.0、HTTP/1.1、HTTP/2和HTTP/3之间的主要区别：\r\n\r\n| 特点 | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |\r\n|----------------|-------------------------------|-------------------------------|-------------------------------|-------------------------------|\r\n| 并发请求 | 不支持并发请求 | 支持有限的并发请求 | 引入多路复用(Multiplexing)，支持更高级别的并发请求 | 引入QUIC协议，通过多路复用和UDP传输支持更高级别的并发请求 |\r\n| 请求头压缩 | 不支持 | 不支持 | 引入HPACK算法对请求头进行压缩 | 引入QPACK算法对请求头进行压缩 |\r\n| 二进制传输 | 不支持 | 不支持 | 使用二进制格式传输数据 | 使用二进制格式传输数据 |\r\n| 流控制 | 不支持 | 不支持 | 支持流控制，可以控制每个流的数据传输速率 | 支持流控制，可以控制每个流的数据传输速率 |\r\n| 服务器推送 | 不支持 | 不支持 | 引入服务器推送机制，服务器可以主动推送资源给客户端 | 引入服务器推送机制，服务器可以主动推送资源给客户端 |\r\n| 连接复用 | 不支持 | 支持持久连接 | 支持多路复用，多个请求可以通过单个连接并行处理 | 支持多路复用，多个请求可以通过单个连接并行处理 |\r\n| 安全性 | 不支持 | 引入HTTPS协议，支持加密传输 | 引入HTTPS协议，支持加密传输 | 引入HTTPS协议，支持加密传输 |\r\n| 可靠性 | 不支持 | 不支持 | 支持头部压缩、流控制和服务器推送，提升传输的可靠性 | 引入QUIC协议，通过UDP传输提升传输的可靠性 |\r\n| 开发复杂性 | 简单 | 对开发者较友好 | 引入了新的概念和协议，对开发者相对复杂 | 依赖QUIC协议，对开发者相对复杂 |\r\n| 缓存机制 | 支持简单的请求响应缓存 | 引入了更强大的缓存控制机制，如ETag、Cache-Control等 | 引入了新的缓存机制，如Server Push、Priority等 | 类似HTTP/2，但通过QUIC对底层的传输进行了优化 |\r\n| 底层协议 | 基于TCP | 基于TCP | 基于TCP或基于TLS的加密传输 | 基于QUIC（Quick UDP Internet Connections） |\r\n| 连接管理 | 每个请求/响应都需要建立和关闭连接 | 引入了持久连接，通过keep-alive头部保持连接 | 通过单个连接并行处理多个请求/响应 | 通过QUIC的连接复用和多路复用进行处理 |\r\n| 传输效率 | 每个请求/响应都需要耗费时间来建立和关闭连接，浪费带宽 | 连接复用有助于减少建立连接的开销，并提高传输效率 | 通过多路复用、头部压缩等机制提高传输效率 | 通过QUIC的特性如连接复用、多路复用等提高传输效率 |\r\n| 对丢包和延迟的影响 | 对丢包和延迟的恢复较慢。一个请求阻塞可能导致后续请求也受到影响 | 对丢包和延迟的恢复较快。使用流的方式可以并行处理请求 | 对丢包和延迟的恢复较快。使用流的方式可以并行处理请求 | 对丢包和延迟的恢复较快，QUIC通过UDP传输有利于降低延迟和丢包的影响 |\r\n| 适用场景 | 简单的Web页面和静态资源 | 大多数Web应用程序 | 复杂的Web应用程序，需要更高的传输效率 | 复杂的Web应用程序，需要更高的传输效率和减少延迟 |\r\n",{"_58":459,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/528/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/528/timeline",{"_58":462,"_60":61,"_62":463,"_64":464,"_66":465,"_68":466,"_70":467,"_72":468,"_74":469,"_76":470,"_78":471,"_111":472,"_131":132,"_133":24,"_134":-5,"_135":479,"_137":480,"_159":152,"_153":482,"_155":483,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":484,"_170":485,"_176":486,"_178":487,"_190":489,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/527","https://api.github.com/repos/pro-collection/interview-question/issues/527/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/527/comments","https://api.github.com/repos/pro-collection/interview-question/issues/527/events","https://github.com/pro-collection/interview-question/issues/527",1861823498,"I_kwDOJGDC6c5u-SwK",527,"常见的请求头和响应头",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[473,474],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":475,"_72":476,"_58":477,"_117":478,"_119":129,"_121":24,"_122":130},5316900032,"LA_kwDOJGDC6c8AAAABPOl0wA","https://api.github.com/repos/pro-collection/interview-question/labels/%E4%BA%AC%E4%B8%9C","京东",[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":481,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-22T16:32:26Z","2023-08-22T16:32:57Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**通用头部字段**\r\n\r\n指的是在请求头和响应头中都可以使用的字段\r\n\r\n| 通用字段 | 作用 |\r\n| ----------------- | --------------------------------------------- |\r\n| Date | 表示报文创建的时间 |\r\n| Connection | 表示内部使用的TCP连接类型，keep-alive / close |\r\n| **Cache-Control** | 控制http缓存的行为 |\r\n| Transfer-Encoding | 传输报文时候的编码方式 |\r\n| Upgrade | 要求客户端升级协议 |\r\n\r\n\r\n\r\n**请求头字段**\r\n\r\n| 请求头字段 | 作用 |\r\n| ----------------- | ------------------------------------------------------------ |\r\n| Accept | 能正确接收的媒体类型 |\r\n| Accept-Charset | 能正确接收的字符集 |\r\n| Accept-Encoding | 能正确接收的编码格式列表。比如：gzip deflate |\r\n| Accept-Language | 能正确接收的语言列表 |\r\n| Host | 表示服务器的域名 |\r\n| if-Match | **比较两端资源的ETag，只有相等的时候才能正常完成请求** |\r\n| If-Modified-Since | 客户端记录的最后一次修改资源的时间，如果小于服务端最后一次修改的时间，则会返回200；否则返回304，去缓存中获取。 |\r\n| if-None-Match | 客户端记录的当前资源的Etag，如果和服务端不匹配，说明有了新的修改，返回200；否则返回304 |\r\n| User-Agent | 客户端的信息 |\r\n| Range | 片段请求中，表示请求资源中的某一个部分 |\r\n| Referer | 表示**当前是在哪个地址上请求这个资源** |\r\n| Cookie | 一些存在前端的信心，比如用户登录的信息。每次请求的时候都会带到后端 |\r\n\r\n\r\n\r\n**响应头字段**\r\n\r\n| 字段 | 作用 |\r\n| -------------------------------- | ----------------------------------------------------------- |\r\n| **Content-Type** | 表示内容的媒体类型，text/html;charset=UTF-8 |\r\n| Content-Encoding | 告诉客户端内容的编码格式 |\r\n| Content-Language | 表示返回内容使用的语言 |\r\n| Content-Length | 表示响应体的长度 |\r\n| Content-Range | 表示返回的实体的片段范围 |\r\n| Content-Location | 表示返回数据的备用地址 |\r\n| **Location** | 表示资源重定向之后的地址 |\r\n| Expires | 表示强缓存资源的过期时间 |\r\n| Last-Modified | 服务端记录的资源修改的最后时间，和If-Modified-Since配合使用 |\r\n| ETag | 服务端记录的资源标识，和if-None-Match配合使用 |\r\n| Allow | 当前资源允许的请求方法 |\r\n| **Access-Control-Allow-Origin** | 表示哪些网站可以跨域访问当前的资源，CORS |\r\n| Access-Control-Allow-Methods | 表示允许使用的方法 |\r\n| Access-Control-Allow-Credentials | 表示CORS请求中是否可以带Cookie |\r\n",{"_58":488,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/527/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/527/timeline",{"_58":491,"_60":61,"_62":492,"_64":493,"_66":494,"_68":495,"_70":496,"_72":497,"_74":498,"_76":499,"_78":500,"_111":501,"_131":132,"_133":24,"_134":-5,"_135":508,"_137":509,"_159":152,"_153":511,"_155":512,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":513,"_170":514,"_176":515,"_178":516,"_190":518,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/501","https://api.github.com/repos/pro-collection/interview-question/issues/501/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/501/comments","https://api.github.com/repos/pro-collection/interview-question/issues/501/events","https://github.com/pro-collection/interview-question/issues/501",1826641319,"I_kwDOJGDC6c5s4FWn",501,"TCP/IP五层协议是什么？【热度: 548】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[502,503],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":504,"_72":505,"_58":506,"_117":507,"_119":129,"_121":24,"_122":130},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":510,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-07-28T15:34:24Z","2023-07-28T15:34:48Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：TCP/IP协议\r\n\r\n当提到五层协议时，通常是指TCP/IP模型的五层协议，即物理层、数据链路层、网络层、传输层和应用层。下面是对每一层的详细解释以及一些应用场景的例子：\r\n\r\n1. 物理层（Physical Layer）：物理层是网络通信的最底层，它负责传输比特流，将数据从一个节点通过物理介质传输到另一个节点。它包括了电缆、光纤、无线信号等物理媒介以及相关的传输设备和接口。应用场景包括有线以太网、Wi-Fi、蓝牙、光纤通信等。\r\n\r\n2. 数据链路层（Data Link Layer）：数据链路层负责将比特流划分为数据帧，并提供可靠的数据传输。它通过物理地址（MAC地址）识别网络设备，进行数据传输的控制和错误检测。应用场景包括以太网、局域网（LAN）、无线局域网（WLAN）、以及网桥、交换机等设备。\r\n\r\n3. 网络层（Network Layer）：网络层负责将数据包从源主机传输到目标主机，并提供寻址、路由选择和分组转发等功能。它使用IP（Internet Protocol）协议来实现这些功能，同时支持多种路由算法和IP寻址方案。常见的应用场景包括互联网、路由器、IP地址分配等。\r\n\r\n4. 传输层（Transport Layer）：传输层负责在网络中的两个主机之间提供端到端的可靠或不可靠的数据传输。主要有TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）两个协议。TCP提供可靠的数据传输，适用于需要保证数据完整性和顺序的应用场景，如网页浏览、文件传输等。UDP则提供不可靠但更快速的数据传输，适用于实时性要求较高的应用场景，如音视频传输、在线游戏等。\r\n\r\n5. 应用层（Application Layer）：应用层负责特定应用程序之间的通信服务。它定义了数据的格式和表示方式，包括HTTP（网页浏览）、FTP（文件传输）、SMTP（电子邮件）、DNS（域名系统）等协议。应用层协议提供了用户与网络之间的接口，使得应用程序能够通过网络进行通信。\r\n\r\n这些是TCP/IP五层协议的详细解释和一些常见的应用场景示例。通过分层的设计，这些协议能够协同工作，实现可靠、高效的网络通信。\r\n",{"_58":517,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/501/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/501/timeline",{"_58":520,"_60":61,"_62":521,"_64":522,"_66":523,"_68":524,"_70":525,"_72":526,"_74":527,"_76":528,"_78":529,"_111":530,"_131":132,"_133":24,"_134":-5,"_135":537,"_137":538,"_159":152,"_153":540,"_155":541,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":542,"_170":543,"_176":544,"_178":545,"_190":547,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/499","https://api.github.com/repos/pro-collection/interview-question/issues/499/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/499/comments","https://api.github.com/repos/pro-collection/interview-question/issues/499/events","https://github.com/pro-collection/interview-question/issues/499",1822753118,"I_kwDOJGDC6c5spQFe",499,"如何封装一个请求，让其多次调用的时候，实际只发起一个请求的时候，返回同一份结果【热度: 636】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[531,532],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":533,"_72":534,"_58":535,"_117":536,"_119":129,"_121":24,"_122":130},5312231007,"LA_kwDOJGDC6c8AAAABPKI2Xw","https://api.github.com/repos/pro-collection/interview-question/labels/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4","阿里巴巴",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":539,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-07-26T16:15:45Z","2023-07-26T16:15:46Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：defer函数、请求结果缓存在JS内存\n\n最优解： **使用deferred思想来实现请求的等待队列，可以借助Promise和async/await语法**。\n\n下面是使用`deferred`思想来实现的代码示例：\n\n```javascript\nclass Deferred {\n constructor() {\n this.promise = new Promise((resolve, reject) => {\n this.resolve = resolve;\n this.reject = reject;\n });\n }\n}\n\n// 创建一个全局的锁标识\nlet lock = false;\n\n// 创建一个缓存对象\nconst cache = {};\n\n// 创建一个等待队列数组\nconst waitingRequests = [];\n\n// 封装请求函数\nasync function request(url, params) {\n const cacheKey = `${url}-${JSON.stringify(params)}`;\n\n // 判断锁的状态\n if (lock) {\n const deferred = new Deferred();\n // 如果锁已经被占用，将请求添加到等待队列中\n waitingRequests.push({\n deferred,\n cacheKey\n });\n await deferred.promise;\n return cache[cacheKey];\n }\n\n // 设置锁的状态为true，表示当前请求正在执行\n lock = true;\n\n try {\n // 发起实际的请求\n const response = await fetch(url, params);\n const data = await response.json();\n // 将结果存入缓存对象\n cache[cacheKey] = data;\n return data;\n } finally {\n // 释放锁，将锁的状态设置为false\n lock = false;\n\n // 处理等待队列中的请求\n if (waitingRequests.length > 0) {\n const request = waitingRequests.shift();\n request.deferred.resolve(cache[request.cacheKey]);\n }\n }\n}\n\n// 调用请求函数\nrequest('https://api.example.com/data', { method: 'GET' })\n .then(data => {\n // 处理请求结果\n console.log(data);\n });\n\n// 同时发起另一个请求\nrequest('https://api.example.com/data', { method: 'GET' })\n .then(data => {\n // 直接从缓存中获取结果，而不发起实际的请求\n console.log(data);\n });\n```\n\n在上述代码中，`Deferred`类用于创建一个延迟对象，其中`promise`属性是一个`Promise`对象，`resolve`和`reject`方法分别用于解决和拒绝该延迟对象的`promise`。通过`await`关键字等待延迟对象的`promise`完成，当锁被占用时，将请求添加到等待队列中，并使用`await`等待对应的延迟对象的`promise`完成后再返回结果。当请求完成后，解锁并处理等待队列中的请求。\n",{"_58":546,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/499/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/499/timeline",{"_58":549,"_60":61,"_62":550,"_64":551,"_66":552,"_68":553,"_70":554,"_72":555,"_74":556,"_76":557,"_78":558,"_111":559,"_131":132,"_133":24,"_134":-5,"_135":562,"_137":563,"_159":152,"_153":565,"_155":566,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":567,"_170":568,"_176":569,"_178":570,"_190":572,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/498","https://api.github.com/repos/pro-collection/interview-question/issues/498/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/498/comments","https://api.github.com/repos/pro-collection/interview-question/issues/498/events","https://github.com/pro-collection/interview-question/issues/498",1822741263,"I_kwDOJGDC6c5spNMP",498,"一般项目里面对请求 request 都会做哪些统一封装？【热度: 916】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[560,561],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":533,"_72":534,"_58":535,"_117":536,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":564,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-07-26T16:08:04Z","2023-07-26T16:08:05Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：request封装、request封装功能、request封装作用\n\n1. 统一处理错误：可以在请求封装中统一处理错误，例如网络错误、超时等，并进行统一的错误提示或处理逻辑。\n2. 统一处理认证和授权：可以在请求中添加认证信息，例如在请求头中添加 token，或者在每个请求中验证用户权限。\n3. 统一处理请求配置：可以在请求封装中设置一些全局的请求配置，例如请求超时时间、请求头部信息等。\n4. 统一处理请求拦截和响应拦截：可以在请求发送前和响应返回后进行一些统一的处理，例如请求拦截器可以添加 loading 状态，响应拦截器可以对返回数据进行预处理等。\n5. 统一处理请求取消：可以实现一个请求取消的机制，可以取消重复的请求或者在组件卸载时取消未完成的请求，避免造成资源浪费或者潜在的问题。\n6. 统一处理请求缓存：可以实现请求结果的缓存机制，可以在多次请求相同数据时，直接从缓存中获取，避免重复发送请求。\n7. 统一处理请求重试：在网络不稳定或请求失败时，可以设置请求重试的机制，可以通过封装请求函数来自动进行重试，提高请求的成功率。\n8. 统一处理请求日志：可以在请求封装中添加请求日志记录，方便追踪和排查问题。\n9. 统一处理请求埋点：可以在请求发送前后加入一些埋点逻辑，例如统计请求的次数、请求时长等，方便进行性能分析和优化。\n10. 统一处理请求参数加密：可以将敏感数据进行加密，并在请求封装中进行解密操作，提高数据安全性。\n11. 统一处理请求数据格式化：可以对请求的数据进行格式化，例如将请求参数转换为指定的数据格式（如 JSON、XML），或者进行数据的序列化和反序列化操作。\n12. 统一处理请求的并发限制：可以设置请求并发数的限制，避免同时发送过多的请求导致服务器压力过大。\n13. 统一处理请求的响应缓存：可以对请求的响应结果进行缓存，减少对服务器的请求压力，提高性能。\n14. 统一处理请求的重定向：可以对请求的重定向进行统一处理，例如自动跳转到指定的页面或进行指定的操作。\n15. 统一处理请求的跨域问题：可以在请求封装中对跨域请求进行处理，例如设置 CORS 头信息、使用代理等方式来解决跨域问题。\n\n",{"_58":571,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/498/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/498/timeline",{"_58":574,"_60":61,"_62":575,"_64":576,"_66":577,"_68":578,"_70":579,"_72":580,"_74":581,"_76":582,"_78":583,"_111":584,"_131":132,"_133":24,"_134":-5,"_135":587,"_137":588,"_159":152,"_153":590,"_155":591,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":592,"_170":593,"_176":594,"_178":595,"_190":597,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/442","https://api.github.com/repos/pro-collection/interview-question/issues/442/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/442/comments","https://api.github.com/repos/pro-collection/interview-question/issues/442/events","https://github.com/pro-collection/interview-question/issues/442",1748222864,"I_kwDOJGDC6c5oM8OQ",442,"ajax、axios、fetch的区别【热度: 855】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[585,586],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":250,"_72":251,"_58":252,"_117":253,"_119":129,"_121":24,"_122":130},[],{"_58":216,"_68":217,"_62":218,"_70":219,"_72":220,"_74":221,"_76":222,"_122":223,"_147":589,"_149":225,"_151":152,"_131":132,"_153":226,"_155":227,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-06-08T16:01:53Z","2023-06-08T16:01:54Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：ajax、axios、fetch、前端网络请求库\n\nAjax、Axios和Fetch都是用于进行HTTP请求的工具或技术，但它们在实现细节和功能方面有所不同。\n\n1. Ajax（Asynchronous JavaScript and XML）:\n - Ajax是一种用于在后台与服务器进行异步通信的技术。\n - Ajax使用XMLHttpRequest对象发送和接收数据，可以通过JavaScript来更新页面的局部内容，而无需刷新整个页面。\n - Ajax可以通过原生JavaScript编写，或者使用库如jQuery等来简化操作。\n\n2. Axios:\n - Axios是一个基于Promise的HTTP客户端，可以在浏览器和Node.js环境中使用。\n - Axios提供了更简洁、易用的API，支持请求和响应拦截、请求取消、全局配置等功能。\n - Axios可以处理请求的错误，并提供了更方便的错误处理机制。\n - Axios支持在浏览器中自动转换JSON数据，可以方便地发送JSON格式的请求和接收JSON格式的响应。\n\n3. Fetch:\n - Fetch是Web API提供的一种用于发送HTTP请求的新特性，主要用于替代XMLHttpRequest。\n - Fetch使用Promise来处理异步操作，提供了更简洁、灵活的API。\n - Fetch基于Promise设计，可以更好地处理请求和响应，并支持链式调用和异步操作。\n - Fetch支持跨域请求和对请求和响应进行拦截、转换等处理。\n\n区别：\n- Ajax是一种技术概念，而Axios和Fetch是具体的工具或技术实现。\n- Axios相比Ajax和Fetch具有更多的功能和便捷的API，支持更多的扩展和配置。\n- Fetch是基于Promise的新API，相对于Ajax和Axios更为现代化，并且支持更多的特性如跨域请求、拦截器等。\n- Ajax可以通过原生JavaScript或库来实现，Axios和Fetch是专门的库。\n- Axios和Fetch提供了更好的错误处理机制，而Ajax在错误处理方面相对简单。\n\n选择使用哪种工具或技术取决于具体的需求和项目情况。如果需要较低级别的控制和自定义配置，可以选择原生的Ajax或Fetch。而如果需要更丰富的功能和更方便的API，可以选择使用Axios或其他类似的库。\n",{"_58":596,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/442/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/442/timeline",{"_58":599,"_60":61,"_62":600,"_64":601,"_66":602,"_68":603,"_70":604,"_72":605,"_74":606,"_76":607,"_78":608,"_111":609,"_131":132,"_133":24,"_134":-5,"_135":612,"_137":613,"_159":152,"_153":615,"_155":616,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":617,"_170":618,"_176":619,"_178":620,"_190":622,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/413","https://api.github.com/repos/pro-collection/interview-question/issues/413/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/413/comments","https://api.github.com/repos/pro-collection/interview-question/issues/413/events","https://github.com/pro-collection/interview-question/issues/413",1740409549,"I_kwDOJGDC6c5nvIrN",413,"什么是正向代理，反向代理【热度: 1,294】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[610,611],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":339,"_72":340,"_58":341,"_117":342,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":614,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-06-04T14:38:13Z","2023-06-04T14:38:14Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：正向代理反向代理概念\n\n### 概念\n\n正向代理（Forward Proxy）和反向代理（Reverse Proxy）都是常见的代理服务器架构，用于在客户端与目标服务器之间进行中转和处理请求的工作。它们的区别在于代理的位置和作用方式不同。\n\n1. 正向代理：\n - 代理位于客户端与目标服务器之间，代理服务器充当客户端的代表。\n - 客户端发起请求时，请求首先发送给正向代理服务器，然后由代理服务器转发请求给目标服务器，目标服务器将响应返回给代理服务器，最后代理服务器再将响应返回给客户端。\n - 客户端并不直接与目标服务器通信，而是通过正向代理服务器进行中转。\n - 正向代理常用于客户端访问互联网，提供一些特定的服务，如匿名访问、访问控制、缓存、安全性等。\n\n2. 反向代理：\n - 代理位于目标服务器与客户端之间，代理服务器充当目标服务器的代表。\n - 客户端发起请求时，请求直接发送给反向代理服务器，然后由代理服务器根据配置和负载均衡策略，将请求转发给后端的目标服务器。\n - 客户端并不知道实际提供服务的是哪个目标服务器，而是与反向代理服务器进行通信。\n - 反向代理常用于负载均衡、高可用性、安全性等方面，可以隐藏后端服务器的真实信息，并提供更好的性能和可扩展性。\n \n\n### 区别\n\n下面是正向代理和反向代理的区别以及它们的特点，用表格形式表示：\n\n| 特点 | 正向代理 | 反向代理 |\n|------------------|------------------------------|------------------------------|\n| 位置 | 位于客户端与目标服务器之间 | 位于目标服务器与客户端之间 |\n| 代理角色 | 代理服务器充当客户端的代表 | 代理服务器充当目标服务器的代表|\n| 通信流向 | 客户端 -> 代理服务器 -> 目标服务器 | 客户端 -> 代理服务器 -> 目标服务器 |\n| 目的 | 隐藏客户端的真实信息，提供访问控制、缓存、安全性等 | 隐藏目标服务器的真实信息，提供负载均衡、高可用性、安全性等 |\n| 请求方式 | 客户端发起请求给代理服务器，代理服务器转发请求给目标服务器 | 客户端发起请求给代理服务器，代理服务器根据配置和负载均衡策略转发请求给目标服务器 |\n| 客户端感知 | 客户端知道自己使用了代理服务器 | 客户端不知道实际提供服务的是哪个目标服务器 |\n| 目标服务器感知 | 目标服务器感知到代理服务器的存在 | 目标服务器不感知客户端使用了反向代理 |\n| 应用场景 | 客户端访问互联网，提供匿名访问、访问控制、缓存等特定服务 | 负载均衡、高可用性、安全性、隐藏真实服务器信息等 |\n| 示例 | 企业内网用户通过代理服务器访问互联网 | 多个服务器集群通过反向代理提供服务 |\n\n这个表格总结了正向代理和反向代理的一些基本特点和区别，以及它们在网络通信中的应用场景。需要根据具体的需求和场景来选择适合的代理方式。\n\n\n**总结**：\n正向代理位于客户端与目标服务器之间，代理服务器充当客户端的代表；反向代理位于目标服务器与客户端之间，代理服务器充当目标服务器的代表。正向代理隐藏了客户端的真实信息，反向代理隐藏了目标服务器的真实信息。它们的作用和使用场景不同，但都能提供一定程度的代理和中转功能，增加了网络通信的灵活性和安全性。\n",{"_58":621,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/413/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/413/timeline",{"_58":624,"_60":61,"_62":625,"_64":626,"_66":627,"_68":628,"_70":629,"_72":630,"_74":631,"_76":632,"_78":633,"_111":634,"_131":132,"_133":24,"_134":-5,"_135":637,"_137":638,"_159":152,"_153":640,"_155":641,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":642,"_170":643,"_176":644,"_178":645,"_190":647,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/412","https://api.github.com/repos/pro-collection/interview-question/issues/412/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/412/comments","https://api.github.com/repos/pro-collection/interview-question/issues/412/events","https://github.com/pro-collection/interview-question/issues/412",1740406213,"I_kwDOJGDC6c5nvH3F",412,"什么是同源策略【热度: 1,430】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[635,636],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":368,"_72":369,"_58":370,"_117":371,"_119":129,"_121":24,"_122":130},[],{"_58":256,"_68":257,"_62":258,"_70":259,"_72":260,"_74":195,"_76":261,"_122":262,"_147":639,"_149":264,"_151":152,"_131":132,"_153":265,"_155":266,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-06-04T14:31:40Z","2023-06-04T14:31:41Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"**关键词**：同源策略限制了什么资源\n\n同源策略（Same-Origin Policy）是一种浏览器安全机制，用于限制不同源（域名、协议、端口）之间的交互。它是一种重要的安全措施，用于保护用户的隐私和安全，防止恶意网站通过跨域请求获取用户的敏感信息或进行恶意操作。\n\n同源策略要求网页资源（如JavaScript、CSS、图片等）只能与来源相同的资源进行交互，即只能与相同域名、相同协议和相同端口的资源进行通信。例如，一个网页加载自`https://www.example.com`域名下的资源，就只能与同一域名下的其他资源进行交互，无法直接访问其他域名的资源。\n\n同源策略主要限制了以下几种行为：\n\n1. DOM访问限制：不同源的页面无法通过JavaScript等方式直接访问对方的DOM元素，即无法获取或修改对方页面的内容。\n\n2. Cookie、LocalStorage和IndexDB限制：不同源的页面无法读取对方设置的Cookie、LocalStorage和IndexDB存储。\n\n3. AJAX请求限制：XMLHttpRequest、Fetch等网络请求在跨域时受到限制，通常无法发送跨域请求。\n\n同源策略的存在有效地防止了跨站脚本攻击（XSS）和跨站请求伪造（CSRF）等安全威胁。如果需要在不同源之间进行数据交互，可以通过服务器端的代理或使用CORS（跨源资源共享）等技术来实现。\n\n**需要注意的是，同源策略只是浏览器的安全策略之一，而并非所有的网络请求都受到同源策略的限制。例如，通过`