跳至主要內容

计算机网络

Ming1网络计算机网络大约 35 分钟约 10425 字

很多技术的理论概念实际工作中很少用得到，也不用修改配置，正常使用也不会出什么问题，不知道也不影响日常工作。

但公司笔试、面试就是喜欢问，就好像理论文化课，学了工作基本用不到，但任何考试都必考！（高考、考研、公务员、教师）

你能怎么办？想进这家公司工作；想考研/考公，大家都一样，该背的背、该记的记。除非你有其他特别擅长的技能，让人能忽略你其他的缺陷。

说明：文档内容多数是从网络博客整理搬运而来，在每个章节的开头有整体标明参考来源，仅供个人参考学习。如有侵害到原创作者的利益，请联系 m1yellow@163.com 处理。

HTTP

简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP是基于客户端/服务端（C/S）的架构模型，通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。

消息结构

客户端请求消息

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

img

服务器响应消息

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

img

请求方法

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序号方法描述
1GET请求指定的页面信息，并返回实体主体。
2HEAD类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
3POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4PUT从客户端向服务器传送的数据取代指定的文档的内容。
5DELETE请求服务器删除指定的页面。
6CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7OPTIONS返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
8TRACE回显服务器收到的请求，主要用于测试或诊断。
9PATCH是对 PUT 方法的补充，用来对已知资源进行局部更新 。

Header 头部信息

可以直接在浏览器 - 审查元素（ctrl+shift+i） - network，点击具体的接口请求，即可查看详细的头部信息。

General

Request URL: https://www.m1yellow.cn/api/home
Request Method: GET
Status Code: 200 
Remote Address: 43.129.189.39:443
Referrer Policy: strict-origin-when-cross-origin

Request

Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7
Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOjEsImV4cCI6MTYzMTMzNjAyMSwiaWF0IjoxNjMxMzI4ODIxLCJ1c2VybmFtZSI6ImFkbWluIn0.csdp41MudoH1WqN-IMaYxxK_eBuHkURdZs4xYmr4TyMqSPj22P7zaan6yTi9gDsuAGNoREGA0-uVermSKGza_w
Connection: keep-alive
Host: www.m1yellow.cn
Referer: https://www.m1yellow.cn/
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Response

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sat, 11 Sep 2021 11:42:34 GMT
Pragma: no-cache
Server: nginx
Transfer-Encoding: chunked
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
应答头说明
Allow服务器支持哪些请求方法（如GET、POST等）。
Content-Encoding文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。
Content-Length表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。
Content-Type表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。
Date当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
Expires应该在什么时候认为文档已经过期，从而不再缓存它？
Last-Modified文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。
Location表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
Refresh表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。 注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。 注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV="Refresh" ...＞。 注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。
Server服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。
Set-Cookie设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。
WWW-Authenticate客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。 注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。

状态码

HTTP状态码分类

分类分类描述
1xx信息，服务器收到请求，需要请求者继续执行操作
2xx成功，操作被成功接收并处理
3xx重定向，需要进一步的操作以完成请求
4xx客户端错误，请求包含语法错误或无法完成请求
5xx服务器错误，服务器在处理请求的过程中发生了错误

HTTP状态码列表

200 401 403 404 500

状态码状态码英文名称中文描述
100Continue继续。到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应
101Switching Protocols切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200OK请求成功。一般用于GET与POST请求
201Created已创建。成功请求并创建了新的资源
202Accepted已接受。已经接受请求，但未处理完成
203Non-Authoritative Information非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204No Content无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205Reset Content重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206Partial Content部分内容。服务器成功处理了部分GET请求
300Multiple Choices多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301Moved Permanently永久移动/永久性重定向。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302Found临时移动/临时性重定向。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303See Other查看其它地址。与301类似。使用GET和POST请求查看
304Not Modified未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305Use Proxy使用代理。所请求的资源必须通过代理访问
306Unused已经被废弃的HTTP状态码
307Temporary Redirect临时重定向。与302类似。使用GET请求重定向。要求浏览器不会把重定向请求的 post 方法改成 get 方法
400Bad Request客户端请求报文存在语法错误，服务器无法理解
401Unauthorized请求要求用户的身份认证
402Payment Required保留，将来使用
403Forbidden服务器理解请求客户端的请求，但是拒绝执行此请求
404Not Found服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405Method Not Allowed客户端请求中的方法被禁止
406Not Acceptable服务器无法根据客户端请求的内容特性完成请求
407Proxy Authentication Required请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408Request Time-out服务器等待客户端发送的请求时间过长，超时
409Conflict服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410Gone客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411Length Required服务器无法处理客户端发送的不带Content-Length的请求信息
412Precondition Failed客户端请求信息的先决条件错误
413Request Entity Too Large由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414Request-URI Too Large请求的URI过长（URI通常为网址），服务器无法处理
415Unsupported Media Type服务器无法处理请求附带的媒体格式
416Requested range not satisfiable客户端请求的范围无效
417Expectation Failed服务器无法满足Expect的请求头信息
500Internal Server Error服务器内部错误，无法完成请求
501Not Implemented服务器不支持请求的功能，无法完成请求
502Bad Gateway作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503Service Unavailable由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504Gateway Time-out充当网关或代理的服务器，未及时从远端服务器获取请求
505HTTP Version not supported服务器不支持请求的HTTP协议的版本，无法完成处理

Content-Type

Content-Type（内容类型），一般是指网页中存在的 Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些 PHP 网页点击的结果却是下载一个文件或一张图片的原因。

Content-Type 标头告诉客户端实际返回的内容的内容类型。

语法格式：

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

实例：

img

常见的媒体格式类型如下：

  • text/html ： HTML格式
  • text/plain ：纯文本格式
  • text/xml ： XML格式
  • image/gif ：gif图片格式
  • image/jpeg ：jpg图片格式
  • image/png：png图片格式

以application开头的媒体格式类型：

  • application/xhtml+xml ：XHTML格式
  • application/xml： XML数据格式
  • application/atom+xml ：Atom XML聚合格式
  • application/json： JSON数据格式
  • application/pdf：pdf格式
  • application/msword ： Word文档格式
  • application/octet-stream ： 二进制流数据（如常见的文件下载）
  • application/x-www-form-urlencoded ： form表单中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

另外一种常见的媒体格式是上传文件之时使用的：

  • multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

HTTP content-type 对照表

文件扩展名Content-Type(Mime-Type)文件扩展名Content-Type(Mime-Type)
.*（ 二进制流，不知道下载文件类型）application/octet-stream.tifimage/tiff
.001application/x-001.301application/x-301
.323text/h323.906application/x-906
.907drawing/907.a11application/x-a11
.acpaudio/x-mei-aac.aiapplication/postscript
.aifaudio/aiff.aifcaudio/aiff
.aiffaudio/aiff.anvapplication/x-anv
.asatext/asa.asfvideo/x-ms-asf
.asptext/asp.asxvideo/x-ms-asf
.auaudio/basic.avivideo/avi
.awfapplication/vnd.adobe.workflow.biztext/xml
.bmpapplication/x-bmp.botapplication/x-bot
.c4tapplication/x-c4t.c90application/x-c90
.calapplication/x-cals.catapplication/vnd.ms-pki.seccat
.cdfapplication/x-netcdf.cdrapplication/x-cdr
.celapplication/x-cel.cerapplication/x-x509-ca-cert
.cg4application/x-g4.cgmapplication/x-cgm
.citapplication/x-cit.classjava/*
.cmltext/xml.cmpapplication/x-cmp
.cmxapplication/x-cmx.cotapplication/x-cot
.crlapplication/pkix-crl.crtapplication/x-x509-ca-cert
.csiapplication/x-csi.csstext/css
.cutapplication/x-cut.dbfapplication/x-dbf
.dbmapplication/x-dbm.dbxapplication/x-dbx
.dcdtext/xml.dcxapplication/x-dcx
.derapplication/x-x509-ca-cert.dgnapplication/x-dgn
.dibapplication/x-dib.dllapplication/x-msdownload
.docapplication/msword.dotapplication/msword
.drwapplication/x-drw.dtdtext/xml
.dwfModel/vnd.dwf.dwfapplication/x-dwf
.dwgapplication/x-dwg.dxbapplication/x-dxb
.dxfapplication/x-dxf.ednapplication/vnd.adobe.edn
.emfapplication/x-emf.emlmessage/rfc822
.enttext/xml.epiapplication/x-epi
.epsapplication/x-ps.epsapplication/postscript
.etdapplication/x-ebx.exeapplication/x-msdownload
.faximage/fax.fdfapplication/vnd.fdf
.fifapplication/fractals.fotext/xml
.frmapplication/x-frm.g4application/x-g4
.gbrapplication/x-gbr.application/x-
.gifimage/gif.gl2application/x-gl2
.gp4application/x-gp4.hglapplication/x-hgl
.hmrapplication/x-hmr.hpgapplication/x-hpgl
.hplapplication/x-hpl.hqxapplication/mac-binhex40
.hrfapplication/x-hrf.htaapplication/hta
.htctext/x-component.htmtext/html
.htmltext/html.htttext/webviewhtml
.htxtext/html.icbapplication/x-icb
.icoimage/x-icon.icoapplication/x-ico
.iffapplication/x-iff.ig4application/x-g4
.igsapplication/x-igs.iiiapplication/x-iphone
.imgapplication/x-img.insapplication/x-internet-signup
.ispapplication/x-internet-signup.IVFvideo/x-ivf
.javajava/*.jfifimage/jpeg
.jpeimage/jpeg.jpeapplication/x-jpe
.jpegimage/jpeg.jpgimage/jpeg
.jpgapplication/x-jpg.jsapplication/x-javascript
.jsptext/html.la1audio/x-liquid-file
.larapplication/x-laplayer-reg.latexapplication/x-latex
.lavsaudio/x-liquid-secure.lbmapplication/x-lbm
.lmsffaudio/x-la-lms.lsapplication/x-javascript
.ltrapplication/x-ltr.m1vvideo/x-mpeg
.m2vvideo/x-mpeg.m3uaudio/mpegurl
.m4evideo/mpeg4.macapplication/x-mac
.manapplication/x-troff-man.mathtext/xml
.mdbapplication/msaccess.mdbapplication/x-mdb
.mfpapplication/x-shockwave-flash.mhtmessage/rfc822
.mhtmlmessage/rfc822.miapplication/x-mi
.midaudio/mid.midiaudio/mid
.milapplication/x-mil.mmltext/xml
.mndaudio/x-musicnet-download.mnsaudio/x-musicnet-stream
.mochaapplication/x-javascript.movievideo/x-sgi-movie
.mp1audio/mp1.mp2audio/mp2
.mp2vvideo/mpeg.mp3audio/mp3
.mp4video/mpeg4.mpavideo/x-mpg
.mpdapplication/vnd.ms-project.mpevideo/x-mpeg
.mpegvideo/mpg.mpgvideo/mpg
.mpgaaudio/rn-mpeg.mppapplication/vnd.ms-project
.mpsvideo/x-mpeg.mptapplication/vnd.ms-project
.mpvvideo/mpg.mpv2video/mpeg
.mpwapplication/vnd.ms-project.mpxapplication/vnd.ms-project
.mtxtext/xml.mxpapplication/x-mmxp
.netimage/pnetvue.nrfapplication/x-nrf
.nwsmessage/rfc822.odctext/x-ms-odc
.outapplication/x-out.p10application/pkcs10
.p12application/x-pkcs12.p7bapplication/x-pkcs7-certificates
.p7capplication/pkcs7-mime.p7mapplication/pkcs7-mime
.p7rapplication/x-pkcs7-certreqresp.p7sapplication/pkcs7-signature
.pc5application/x-pc5.pciapplication/x-pci
.pclapplication/x-pcl.pcxapplication/x-pcx
.pdfapplication/pdf.pdfapplication/pdf
.pdxapplication/vnd.adobe.pdx.pfxapplication/x-pkcs12
.pglapplication/x-pgl.picapplication/x-pic
.pkoapplication/vnd.ms-pki.pko.plapplication/x-perl
.plgtext/html.plsaudio/scpls
.pltapplication/x-plt.pngimage/png
.pngapplication/x-png.potapplication/vnd.ms-powerpoint
.ppaapplication/vnd.ms-powerpoint.ppmapplication/x-ppm
.ppsapplication/vnd.ms-powerpoint.pptapplication/vnd.ms-powerpoint
.pptapplication/x-ppt.prapplication/x-pr
.prfapplication/pics-rules.prnapplication/x-prn
.prtapplication/x-prt.psapplication/x-ps
.psapplication/postscript.ptnapplication/x-ptn
.pwzapplication/vnd.ms-powerpoint.r3ttext/vnd.rn-realtext3d
.raaudio/vnd.rn-realaudio.ramaudio/x-pn-realaudio
.rasapplication/x-ras.ratapplication/rat-file
.rdftext/xml.recapplication/vnd.rn-recording
.redapplication/x-red.rgbapplication/x-rgb
.rjsapplication/vnd.rn-realsystem-rjs.rjtapplication/vnd.rn-realsystem-rjt
.rlcapplication/x-rlc.rleapplication/x-rle
.rmapplication/vnd.rn-realmedia.rmfapplication/vnd.adobe.rmf
.rmiaudio/mid.rmjapplication/vnd.rn-realsystem-rmj
.rmmaudio/x-pn-realaudio.rmpapplication/vnd.rn-rn_music_package
.rmsapplication/vnd.rn-realmedia-secure.rmvbapplication/vnd.rn-realmedia-vbr
.rmxapplication/vnd.rn-realsystem-rmx.rnxapplication/vnd.rn-realplayer
.rpimage/vnd.rn-realpix.rpmaudio/x-pn-realaudio-plugin
.rsmlapplication/vnd.rn-rsml.rttext/vnd.rn-realtext
.rtfapplication/msword.rtfapplication/x-rtf
.rvvideo/vnd.rn-realvideo.samapplication/x-sam
.satapplication/x-sat.sdpapplication/sdp
.sdwapplication/x-sdw.sitapplication/x-stuffit
.slbapplication/x-slb.sldapplication/x-sld
.slkdrawing/x-slk.smiapplication/smil
.smilapplication/smil.smkapplication/x-smk
.sndaudio/basic.soltext/plain
.sortext/plain.spcapplication/x-pkcs7-certificates
.splapplication/futuresplash.spptext/xml
.ssmapplication/streamingmedia.sstapplication/vnd.ms-pki.certstore
.stlapplication/vnd.ms-pki.stl.stmtext/html
.styapplication/x-sty.svgtext/xml
.swfapplication/x-shockwave-flash.tdfapplication/x-tdf
.tg4application/x-tg4.tgaapplication/x-tga
.tifimage/tiff.tifapplication/x-tif
.tiffimage/tiff.tldtext/xml
.topdrawing/x-top.torrentapplication/x-bittorrent
.tsdtext/xml.txttext/plain
.uinapplication/x-icq.ulstext/iuls
.vcftext/x-vcard.vdaapplication/x-vda
.vdxapplication/vnd.visio.vmltext/xml
.vpgapplication/x-vpeg005.vsdapplication/vnd.visio
.vsdapplication/x-vsd.vssapplication/vnd.visio
.vstapplication/vnd.visio.vstapplication/x-vst
.vswapplication/vnd.visio.vsxapplication/vnd.visio
.vtxapplication/vnd.visio.vxmltext/xml
.wavaudio/wav.waxaudio/x-ms-wax
.wb1application/x-wb1.wb2application/x-wb2
.wb3application/x-wb3.wbmpimage/vnd.wap.wbmp
.wizapplication/msword.wk3application/x-wk3
.wk4application/x-wk4.wkqapplication/x-wkq
.wksapplication/x-wks.wmvideo/x-ms-wm
.wmaaudio/x-ms-wma.wmdapplication/x-ms-wmd
.wmfapplication/x-wmf.wmltext/vnd.wap.wml
.wmvvideo/x-ms-wmv.wmxvideo/x-ms-wmx
.wmzapplication/x-ms-wmz.wp6application/x-wp6
.wpdapplication/x-wpd.wpgapplication/x-wpg
.wplapplication/vnd.ms-wpl.wq1application/x-wq1
.wr1application/x-wr1.wriapplication/x-wri
.wrkapplication/x-wrk.wsapplication/x-ws
.ws2application/x-ws.wsctext/scriptlet
.wsdltext/xml.wvxvideo/x-ms-wvx
.xdpapplication/vnd.adobe.xdp.xdrtext/xml
.xfdapplication/vnd.adobe.xfd.xfdfapplication/vnd.adobe.xfdf
.xhtmltext/html.xlsapplication/vnd.ms-excel
.xlsapplication/x-xls.xlwapplication/x-xlw
.xmltext/xml.xplaudio/scpls
.xqtext/xml.xqltext/xml
.xquerytext/xml.xsdtext/xml
.xsltext/xml.xslttext/xml
.xwdapplication/x-xwd.x_bapplication/x-x_b
.sisapplication/vnd.symbian.install.sisxapplication/vnd.symbian.install
.x_tapplication/x-x_t.ipaapplication/vnd.iphone
.apkapplication/vnd.android.package-archive.xapapplication/x-silverlight-app

HTTPS

HTTPS 主要由两部分组成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。

HTTPS 相较 HTTP 不是一种新协议，只是在 HTTP 通信接口部分使用了 SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议来实现。使得 HTTP 先与 SSL 通信，再由 SSL 和 TCP 通信，而不是 HTTP 直接与 TCP 通信，HTTP 和 HTTPS 图示如下：

HTTP 和 HTTPS

加密方式

建立安全的通信通道

  • SSL（Secure Socket Layer）安全套接层
  • TLS（Transport Layer Security ）安全层传输协议

SSL 与 TLS

SSL和TLS都是加密协议，有网络请求的地方就可以使用这两种协议在传输层进行加密，确保数据传输的安全，SSL是TLS的前身，网景在1995年发布了直接发布了SSL 2.0版本，1.0版本没有对外发布。由于漏洞的原因，版本2.0也只是昙花一现，网景在1996年就发布了SSL3.0。随后在1999年的时候，基于SSL3.0版本，网景发布了TLS1.0版本(虽然TLS1.0在SSL3.0基础上的改动不太大，但是这些改动都是非常重要的)。

协议年份
SSL 2.01995
SSL 3.01996
TLS 1.01999
TLS 1.12006
TLS 1.22008
TLS 1.32018

应该使用哪个协议

其实答案很显然，现在应该使用TLS协议，因为在2011年和2015年的时候SSL2.0和SSL3.0就已经分别被弃用了，而且由于漏洞的缘故，如果你的服务器配置了SSL的协议，还得手动将他们禁用掉。所以只给服务器配置TLS协议就好了，有的服务对TLS版本有要求，比如小程序开发，要求TLS版本最低2.0，所以你可以在SSL Server Test查看服务器的证书及协议等配置。

（https://www.jianshu.com/p/cd7b04d6ce82）

对内容进行加密

支付机构，通常在使用了 https 证书加密通信之后，还会对请求和响应的参数内容进行加密，进一步保障数据的安全。

工作流程

HTTPS加密流程

简化版工作流程

img

1.Client发起一个HTTPS（比如https://juejin.cn/user/4283353031252967）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

（https://juejin.cn/post/6844903830916694030）

握手过程

img

客户端：发送hello报文，报文指定自己接受的 SSL/TLS 版本，加密组件等（例如加密算法以及长度）

服务器：同样告诉客户端自己接收的 SSL/TLS 版本，加密组件等信息，不过加密组件是从客户端那里选择

服务器：紧接着发送数字证书，当然，数字证书包含服务器的公钥

客户端：接着客户端给服务器发送一个用来加密的随机密码串。当然，该报文会用公钥进行加密

客户端证书场景

网银登录的时候，需要证书。

意味着每个用户都需要一个证书，需要自己安装。并且这个证书安装好几次都不成功，很烦人。

HTTPS 和 HTTP 的区别

  • 最最重要的区别就是安全性，HTTP 明文传输，不对数据进行加密安全性较差。HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
  • 使用 HTTPS 协议需要申请 CA 证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、DigiCert 和 GlobalSign 等。
  • HTTP 页面响应速度比 HTTPS 快，这个很好理解，由于加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
  • 由于 HTTPS 是建构在 SSL / TLS 之上的 HTTP 协议，所以，要比 HTTP 更耗费服务器资源。
  • HTTPS 和 HTTP 使用的是完全不同的连接方式，用的端口也不一样，前者是 443，后者是 80。

HTTPS 的缺点

  • 在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
  • HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
  • 在现有的证书机制下，中间人攻击依然有可能发生。
  • HTTPS 数字证书费用不低，也会占用更多的服务器资源，导致成本的升高。

TCP

TCP/IP 协议

img

计算机网络体系结构分层

img

三次握手 ★

英文缩写意思：

**（1）序号（sequence number）：**Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

**（2）确认号（acknowledgement number）：**Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

**（3）标志位（Flags）：**共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：

  • URG：紧急指针（urgent pointer）有效。
  • ACK：确认序号有效。
  • PSH：接收方应该尽快将这个报文交给应用层。
  • RST：重置连接。
  • SYN：发起一个新连接。
  • FIN：释放一个连接。

需要注意的是：

  • 不要将确认序号Ack与标志位中的ACK搞混了。
  • 确认方Ack=发起方Seq+1，两端配对。

img

img

img

img

image-20220812031255908

面试题

为什么要三次握手？

三次握手的目的是建立可靠的通讯信道，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

形象例子

以打电话为例 小明 给小红 打电话 小明 ： 喂，小红 听得到么？ 小红： 嗯，我听到你说话了，你能听到我么？ 小明：我能听到你。

只有这三个传输都正确了，才能保障双方是 连通的

使用两次握手行不行？会出现什么问题？

把三次握手改成两次握手，可能会出现连接死锁。

客户端C 与 服务端S 建立连接：

C发送连接请求，S确认受到请求并应答，按照需求，两次握手完成，强行认为连接建立完成。

如果在第二次握手，C没有收到S的应答，而S强行认为C收到了，S开始发送数据，C因为没有收到应答，忽略S发送的数据。

结果，S一直发送数据，C始终忽略数据，进入了死循环，造成连接死锁，会占用大量的CPU资源。

为什么初始化序列号是随机的？固定序列号会出现什么问题？

img

  1. 假设现在A和B使用固定的序号，A使用序号1和B建立tcp连接，发送一个SYN报文，SEQ = 1，经过三次握手后A和B之间就建立tcp连接完成。
  2. 当A和B建立完tcp连接后，然后A又使用相同的序号1向B发送了200字节数据，不过因为网络拥塞问题，这个tcp数据报一直在网络中逗留，并没有立即到达B。
  3. 由于A发送的tcp数据报一直没到达B，正好此时A发生故障并重启，于是B就释放这条tcp连接了。
  4. 然后A重启后又使用序号1和B建立新的tcp连接。
  5. 当tcp连接建立完成后，A又使用序号1向B发送了240字节的数据，不过这次网络很稳定，B马上就收到A发送的这240字节的数据，注意：此时A发送数据是使用的新的tcp连接。
  6. 然后A之前发送的tcp数据报（200字节）经过一段时间后，终于到达B。不过这个tcp数据报是属于之前已经释放的旧的tcp连接，按理来说，B应该把这个数据报丢弃掉才是。但是由于A每次发送报文都使用了相同的序号（SEQ = 1），这可能会让B误认为这200字节是属于新建立的tcp连接的，因此B会对这200字节数据照收不误。这就导致B在收到新tcp连接的数据后，又收到旧tcp连接的数据，从而出现数据乱序的问题。

初始化序列号的目的

由于A和B之间的一个tcp连接通常是由A和B的2个ip地址，2个端口号构成的四元组，因此当A出现了故障把这个tcp连接断开了，之后再以相同的四元组建立新的tcp连接（也就是说A和B两次建立tcp连接都是使用了相同的ip地址和端口），就会出现数据乱序的问题。

换句话说，只要A发送了一个tcp报文段，且这个tcp报文段的四元组和序号，和之前的tcp连接（四元组和序号）相同的话，就会被B确认。这其实反映了tcp的一些缺点，如果被一些恶意攻击者加以利用tcp的这种缺点：选择合适的序号，ip地址和端口的话，就能伪造出一个tcp报文段，从而打断正常的tcp连接。但是初始化序号的方式（通过算法来随机生成序号）就会使序号难以猜出，也就不容易利用这种缺点来进行一些恶意攻击行为。

通过上面所述我们知道，如果A和B之间发送数据每次都使用相同序号的话可能会引发一系列的问题，但是使用不同序号的话，那么B在接收到这个序号为1的tcp报文时，发现这个tcp报文的序号不在新tcp连接的接收范围内时会把这个tcp报文丢弃掉，也就避免了数据乱序的问题。

客户端和服务端双方在建立tcp连接并初始化序列号，那么上面所说的这些情况从一开始就可以避免。另外，tcp在初始化序列号的过程也是比较复杂的，一般来说，这个序列号在报文中占 32 bit，而且序号的生成也是随机的，通常是一个很大的数值，也就是说每个tcp连接使用的序号也是不一样的。

什么是半连接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立连接。服务器会把这种状态下请求连接放在一个队列里，把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

三次握手过程中，可以携带数据吗？

第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据。

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，发起 SYN flood 洪水攻击，这会让服务器花费大量的内存空间来缓存这些报文，这样服务器就更容易被攻击了。

对于第三次握手，此时客户端已经处于连接状态，他已经知道服务器的接收、发送能力是正常的了，所以可以携带数据。

你是看网上博客资料说的不可以是吗？**有没有进一步验证求证呢？**是建议性的不可以带数据，还是协议内部逻辑就作了限制？

有没有直接结果证据，证明第一、第二次握手不能带数据，拿出铁证，比如关键代码、报文验证抓包记录，而不是理论上说带数据会出问题！

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP 有一个保活计时器，客户端出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

四次挥手 ★

img

img

img

image-20220812031526820

面试题

为什么连接的时候是三次握手，关闭的时候却是四次握手

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，还需要第四次。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，可以直接进入CLOSE状态了，但是必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

还有第 2 个理由，避免新旧连接混淆。

在客户端发送完最后一个 ACK 报文段后，在经过 2MSL 时间，就可以使本连接持续的时间内所产生的所有报文都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文。

有些自作主张的路由器会缓存 IP 数据包，如果连接重用了，那么这些延迟收到的包就有可能会跟新连接混在一起。

流量控制

接收方每次发送确认报文的时候，可以告诉发送方的接收窗口大小，当为0时，发送方停止发送，之后发送方开发一个定时器，每隔一段时间发送测试报文去询问接收方的窗口大小

拥塞控制

image-20210913173946933

可靠传输

image-20210913174053760

首部格式

img

img

---Source Port是源端口，16位。

---Destination Port是目的端口，16位。

---Sequence Number是发送数据包中的第一个字节的序列号，32位。

---Acknowledgment Number是确认序列号，32位。

---Data Offset是数据偏移，4位，该字段的值是TCP首部（包括选项）长度除以4。

---标志位： 6位，URG表示Urgent Pointer字段有意义：

ACK表示Acknowledgment Number字段有意义

PSH表示Push功能，RST表示复位TCP连接

SYN表示SYN报文（在建立TCP连接的时候使用）

FIN表示没有数据需要发送了（在关闭TCP连接的时候使用）

Window表示接收缓冲区的空闲空间，16位，用来告诉TCP连接对端自己能够接收的最大数据长度。

---Checksum是校验和，16位。

---Urgent Pointers是紧急指针，16位，只有URG标志位被设置时该字段才有意义，表示紧急数据相对序列号（Sequence Number字段的值）的偏移。

与 UDP 的差别

  • TCP 是面向连接的传输控制协议，而UDP 提供了无连接的数据报服务。

  • TCP 具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP 在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作。

  • UDP 具有较好的实时性，工作效率较 TCP 协议高。在视频直播领域应用较多。

  • UDP 段结构比 TCP 的段结构简单，因此网络开销也小。

  • TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流，为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。比如 HTTP 运用 TCP 进行数据的传输。

UDP

DNS

ICMP

ARP

DHCP

上次编辑于:
贡献者: M1Yellow