HTTP interview questions online many, but the answer is not comprehensive, also will not condensed focus, resulting in children’s shoes and small series are difficult to remember, for these questions small series in the answer at the same time, will focus on refining out convenient memory

1. The difference between HTTP and HTTPS

HTTP is a Hypertext Transfer Protocol (Hypertext Transfer Protocol). HTTP is a Protocol and specification for transmitting Hypertext data, such as text, pictures, audio and video, between two points in the computer world

The main content of HTTP is divided into three parts: Hypertext, Transfer and Protocol.

  • Hypertext is more than just text, it can also transfer pictures, audio, video, and even click on a text or imagehyperlinksThe jump.
  • These concepts can be collectively referred to as data, and transmission is the process in which data is transferred from one end system to another through a series of physical media. Usually we call the party that transmits the packetThe requester, the party receiving the binary packet is calledReply party.
  • Protocol refers to the norms for transferring and managing information on networks (including the Internet). Just as people need to follow certain rules to communicate with each other, computers need to follow certain rules to communicate with each other. These rules are called protocols, but network protocols.

Speaking of HTTP, the TCP/IP network model has to be mentioned, which is usually a five-tier model. As shown in the figure below

However, it can also be divided into four layers, that is, the link layer and the physical layer are expressed as the network interface layer

Another is the OSI seven-layer network model, which adds a presentation layer and a session layer on top of the five-layer protocol

The full name of HTTPS is Hypertext Transfer Protocol Secure. From its name, we can see that HTTPS is more Secure than HTTPS. In fact, HTTPS is not a new application-layer Protocol. It is a combination of HTTP + TLS/SSL, and security is what TLS/SSL does.

In other words, HTTPS is HTTP with SSL on top.

So, what are the main differences between HTTP and HTTPS?

  • At its simplest, HTTP’s protocol in the address bar begins with http://, while HTTPS’s protocol in the address bar begins with https://

    www.cxuanblog.com/ www.cxuanblog.com/

  • HTTP is a protocol without secure encryption. Its transmission process is easy to be monitored by attackers, data is easy to be stolen, and sender and receiver are easy to be forged. HTTPS is a secure protocol, which can solve these problems through key exchange algorithm – signature algorithm – symmetric encryption algorithm – digest algorithm.

  • The default port for HTTP is 80 and the default port for HTTPS is 443.

Summary of main points:

HTTP: plaintext transmission, stateless; HTTPS :SSL+HTTP, encrypted transmission, identity authentication

HTTP: efficient, fast; HTTPS: consumes resources and time

HTTP port: 80; https:443

2. Differences between HTTP Get and Post

HTTP includes many methods. Get and Post are the two most commonly used methods in HTTP. Basically, 99% of HTTP methods are used in Get and Post methods, so it is necessary for us to have a deeper understanding of these two methods.

  • For example, if you type www.cxuanblog.com in the browser address bar, you will send a GET request. The main feature of the get request is to request the server to return the resource, while the post method is usually used for submitting the

    form, which is equivalent to submitting information to the server. Waiting for the server to respond, GET is equivalent to a pull operation and POST is equivalent to a push operation.

  • The get method is not secure, because your request parameters will be spelled after the URL in the process of sending the request, making it easy for attackers to steal your information and cause damage and forgery.

    /test/demo_form.asp? name1=value1&name2=value2

The POST method puts parameters in the request body, which is not visible to the user.

Asp HTTP/1.1 Host: w3schools.com name1=value1&name2=value2Copy the code

  • A GET request has a URL with a length limit, whereas a POST request places parameters and values in the message body, with no requirement for data length.

  • Get requests are actively cached by browsers, whereas POST requests are not, unless set manually.

  • Get requests are harmless when repeated back/forward operations are performed in the browser, while POST operations resubmit the form request.

  • A GET request generates a TCP packet during transmission. Post generates two TCP packets during sending. For get requests, the browser sends both HTTP headers and data, and the server responds with 200 (return data). For POST, the browser sends a header, the server responds with 100 continue, the browser sends data, and the server responds with 200 OK (returns data).

Summary of main points:

  • The get: pull; post:push
  • Get request parameter concatenation is not secure after the URL; The POST request parameters are placed in the body
  • Get has a length limit; Post has no length limit
  • Get is actively cached by the browser. The post will not
  • Get back/forward repeatedly is harmless; The post submits the form again
  • Get sends a single packet. Post sends two

3. What is stateless protocol? Is HTTP a stateless protocol

The Stateless Protocol means that the browser has no memory for transaction processing. For example, a client may close the browser after requesting a web page, and then start the browser again to log in to the site, but the server does not know that the client closed the browser once.

HTTP is a stateless protocol that has no memory for user actions. Most users probably don’t believe that. They probably think that every time they enter a username and password to log in to a site, they will not re-enter the username and password the next time they log in. That’s not really what HTTP does. What does is a mechanism called cookies. It gives the browser the ability to remember.

If your browser allows cookies, viewing the chrome: / / Settings/content/cookies

Which means your memory chip is powered up… When you want the server to send a request, the server sends you an authentication message. When the server receives the request for the first time, it creates a Session space (the Session object is created), generates a sessionId, and passes the ** set-cookie in the response header: JSESSIONID=XXXXXXX ** command to send a response to the client requesting to set cookies; After receiving the response, the client sets a Cookie with **JSESSIONID=XXXXXXX ** on the local client. The Cookie expires at the end of the browser session.

Next, when the client sends a request to the same website each time, the request header will carry the Cookie information (including the sessionId). Then, the server obtains the value named JSESSIONID by reading the Cookie information in the request header and obtains the sessionId of the request. In this way, your browser has the ability to remember.

Another way is to use the JWT mechanism, which is also a mechanism to make your browser memorable. Unlike cookies, JWT is information stored on the client and is widely used in single sign-on situations. JWT has two characteristics

  • JWT Cookie information is stored inThe client, instead of server memory. In other words, JWT can directly authenticate the Token locally. After the authentication, the Token will be sent to the server in the Session with the request. In this way, the server resources can be saved and the Token can be authenticated multiple times.
  • JWT supports cross-domain authentication, Cookies can only be used inThe domain of a single nodeOr itssubdomainThe effective. If they try to access through a third node, they are blocked. Using JWT can solve this problem, using JWT can passMultiple nodesUser authentication, that’s what we call itCross-domain authentication.

Summary of main points:

  • HTTP has no memory of user operations
  • The client sends an HTTP request and the server returns an HTTP Response +set cookie. The client sends an HTTP Request +cookie, and the server returns an HTTP Response

4. Summarize the differences between HTTP1.0/1.1/2.0

The HTTP 1.0

HTTP 1.0 was introduced in 1996, and since then its popularity has been phenomenal.

  • HTTP 1.0 provides only the most basic authentication, and at this point the user name and password are not encrypted, making it easy for prying eyes.
  • HTTP 1.0 was designed to use short links, where each transmission of data goes through TCP’s three-way handshake and four-way wave, which is less efficient.
  • HTTP 1.0 only uses if-Modified-since and Expires in headers as criteria for cache invalidation.
  • HTTP 1.0 does not support breakpoint continuation, which means that all pages and data are sent each time.
  • HTTP 1.0 assumes that only one IP can be bound to each computer, so the URL in the request message does not pass the hostname.

The HTTP 1.1

HTTP 1.1 came three years after HTTP 1.0 was developed, in 1999, with the following changes

  • HTTP 1.1 uses the digest algorithm for authentication
  • HTTP 1.1 uses long connections by default. Long connections are established once and can be transmitted multiple times. After the transmission is complete, the connection can be disconnected only once. The connection duration of a long connection can be specified in the request headerkeep-aliveTo set the
  • HTTP 1.1 added e-tag, if-unmodified-since, if-match, if-none-match and other cache control headers to control cache invalidation.
  • HTTP 1.1 supports breakpoint continuation by using theRangeTo implement.
  • HTTP 1.1 uses virtual networks, where multiple virtual hosts (multi-homed Web Servers) can exist on a single physical server and share a single IP address.

The HTTP 2.0

HTTP 2.0 is a standard developed in 2015 with the following major changes

  • The head of compressionBecause HTTP 1.1 comes up a lotUser-agent, Cookie, Accept, Server, RangeFields like “, “and”, “can take up hundreds or even thousands of bytes, whereas” Body “is often only tens of bytes, leading to a heavy header. The HTTP 2.0 usingHPACKAlgorithm for compression.
  • Binary formatHTTP 2.0 uses a binary format closer to TCP/IP and ditched ASCII to improve parsing efficiency
  • Strengthen the securitySince security has become a top priority, HTTP2.0 generally runs on HTTPS.
  • multiplexingThat is, each request is used for connection sharing. One request corresponds to one ID, so there can be multiple requests on a connection.

5. Describe a common HTTP request header

Common request headers: Generic, Entity, request

Head agreement instructions The sample state
Accept Acceptable response Content Types (‘ content-types’). `Accept: text/plain` fixed
Accept-Charset Acceptable character set `Accept-Charset: utf-8` fixed
Accept-Encoding The encoding of acceptable response content. `Accept-Encoding: gzip, deflate` fixed
Accept-Language List of acceptable response content languages. `Accept-Language: en-US` fixed
Accept-Datetime An acceptable time-dependent version of the response content Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT temporary
Authorization Authentication information of the resource to be authenticated in HTTP Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE== fixed
**Cache-Control** Used to specify whether caching is used in the current request/reply. `Cache-Control: no-cache` fixed
**Connection** The type of connection that the client (browser) wants to use preferentially `Connection: keep-alive`

Connection: Upgrade

 fixed
Cookie An HTTP Cookie Set by the previous server via ‘set-cookie’ (see below) `Cookie: $Version=1; Skin=new; ` Fixed: standard
Content-Length The length of the request body in base 8 `Content-Length: 348` fixed
Content-MD5 The binary MD5 hash value (digitally signed) of the content of the request body, the result encoded in Base64 Content-MD5: oD8dH2sgSW50ZWdyaIEd9D== abandoned
Content-Type MIME type of the request body (for POST and PUT requests) Content-Type: application/x-www-form-urlencoded fixed
**Date** Date and time of sending the message (defined in [RFC 7231] (http://tools.ietf.org/html/rfc7231#section-7.1.1.1) of “HTTP” date format to send) Date: Dec, 26 Dec 2015 17:30:00 GMT fixed
Expect Indicates that the client is asking the server to perform a specific behavior `Expect: 100-continue` fixed
From The email address of the user who initiated this request `From: [email protected]` fixed
Host Indicates the domain name of the server and the port number monitored by the server. If the requested port is the standard port (80) of the corresponding service, the port number can be omitted. `Host: www.itbilu.com:80`

Host: www.itbilu.com

 fixed
If-Match The operation is performed only when the entity provided by the client matches the entity on the server. In methods such as PUT, a resource is updated only if it has not been modified since the last update by a slave user. If-Match: “9jd00cdj34pss9ejqiw39d82f20d0ikd” fixed
If-Modified-Since 304 unmodified is allowed if the corresponding resource has not been modified If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT fixed
If-None-Match Allows 304 Not Modified to be returned if the corresponding content has Not been Modified, referring to hypertext Transfer protocol entity flags If-None-Match: “9jd00cdj34pss9ejqiw39d82f20d0ikd” fixed
If-Range If the entity has not been modified, the missing one or more parts are returned. Otherwise, return the entire new entity If-Range: “9jd00cdj34pss9ejqiw39d82f20d0ikd” fixed
If-Unmodified-Since A response is sent only if the entity has not been modified since a certain time. If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT fixed
Max-Forwards Limits the number of times the message can be forwarded by the proxy and gateway. `Max-Forwards: 10` fixed
Origin Initiate a against [cross-domain resources sharing] (http://itbilu.com/javascript/js/VkiXuUcC.html) request (the request to the server in response to join a ` Access – Control – Allow – Origin ` header, Represents the source that access control allows. `Origin: http://www.itbilu.com` Fixed: standard
Pragma Implementation-specific, these fields can be generated at any time in the request/response chain. `Pragma: no-cache` fixed
Proxy-Authorization Authentication information used to authenticate the agent. Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2== fixed
Range Represents a request for a portion of an entity, byte offset starting at 0. `Range: bytes=500-999` fixed
Referer Represents the previous page visited by the browser, which can be considered to have been brought to the current page by links from previous visits. ‘Referer’ is actually the word ‘Referrer’, but the RFC misspelled the standard and later used ‘Referer’ instead. Referer: http://itbilu.com/nodejs fixed
TE Encoding the way the browser expects to accept transfers: You can use the value in the transfer-encoding response header (and you can also use “Trailers” to say how data is fragmented in Transfer) to indicate that the browser wants to receive some additional fields after the last block of size 0. `TE: trailers,deflate` fixed
User-Agent The browser identity string ` the user-agent: Mozilla /… ` fixed
Upgrade Requires that the server be upgraded to a higher version protocol. Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/ X11 fixed
Via Tell the server which agent made the request. Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1) fixed
Warning A general warning that there may be an error in the entity content body. Warning: 199 Miscellaneous warning fixed

Common response headers:

Response headers instructions The sample state
Access-Control-Allow-Origin Specifies which sites can be ‘shared across domain source resources’ `Access-Control-Allow-Origin: *` temporary
Accept-Patch Specifies the document patch format supported by the server Accept-Patch: text/example; charset=utf-8 fixed
Accept-Ranges The range of content supported by the server `Accept-Ranges: bytes` fixed
Age The duration, in seconds, of the response object in the proxy cache `Age: 12` fixed
Allow Valid actions for a particular resource; `Allow: GET, HEAD` fixed
Cache-Control Notify all caching mechanisms, from the server to the client, of whether or not they can cache the object and for how long. The unit is second `Cache-Control: max-age=3600` fixed
Connection The options expected for the connection `Connection: close` fixed
Content-Disposition A description of a resource with a known MIME type. Based on the response header, the browser can decide whether to act on the returned resource, such as downloading or opening it. Content-Disposition: attachment; filename=”fname.ext” fixed
Content-Encoding The encoding type used to respond to the resource. `Content-Encoding: gzip` fixed
Content-Language Sound on the content of the language used `Content-Language: zh-cn` fixed
Content-Length The length of the response message body, expressed in hexadecimal bytes `Content-Length: 348` fixed
Content-Location A candidate location for the data returned `Content-Location: /index.htm` fixed
Content-MD5 The binary MD5 hash of the response content, encoded in Base64 Content-MD5: IDK0iSsgSW50ZWd0DiJUi== Has been eliminated
Content-Range If it is a response part message, which part of the complete message Content-Range: bytes 21010-47021/47022 fixed
Content-Type The MIME type of the current content Content-Type: text/html; charset=utf-8 fixed
Date This message is sent when the date and time (defined in [RFC 7231] (http://tools.ietf.org/html/rfc7231#section-7.1.1.1) “HTTP date format to represent”) Date: Tue, 15 Nov 1994 08:12:31 GMT fixed
ETag An identifier for a particular version of a resource, usually a message hash ETag: “737060cd8c284d8af7ad3082f209582d” fixed
Expires Specify a date/time after which this response is considered expired Expires: Thu, 01 Dec 1994 16:00:00 GMT Fixed: standard
Last-Modified The last modification date of the requested object (in the hypertext Transfer Protocol date format defined in RFC 7231) Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT fixed
Link Used to indicate the type of relationship with another resource, this type of relationship is defined in [RFC 5988] (https://tools.ietf.org/html/rfc5988) `Link:` ; rel=”alternate” fixed
Location Used when redirecting, or when a new resource is created. Location: http://www.itbilu.com/nodejs fixed
P3P P3P policy Settings P3P: CP=”This is not a P3P policy! fixed
Pragma Depending on the implementation, these response headers may have different effects at different times in the request/response chain `Pragma: no-cache` fixed
Proxy-Authenticate Requires authentication information when accessing the broker. `Proxy-Authenticate: Basic` fixed
Public-Key-Pins Used to prevent intermediate attacks and declare the certificate hash value of the transport layer security protocol in web site authentication Public-Key-Pins: max-age=2592000; Pin – sha256 = “…” ; fixed
Refresh Used for redirection, or when a new resource is created. The redirection will refresh after 5 seconds by default. Refresh: 5; url=http://itbilu.com
Retry-After If an entity is temporarily unavailable, this protocol header is used to tell the client to try again later. The value can be a specific time period (in seconds) or a hypertext Transfer Protocol date.
  • Example 1: Retry – After: 120
  • Example 2: Retry-after: Dec, 26 Dec 2015 17:30:00 GMT

fixed
**Server** Server name ` Server: nginx / 1.6.3 ` fixed
**Set-Cookie** Set the HTTP cookies ` ` Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 Fixed: standard
**Status** The response header field of a generic gateway interface that describes the response status of the current HTTP connection. `Status: 200 OK`
Trailer The ‘Trailer’ user describes the coding information for the block coding in transit `Trailer: Max-Forwards` fixed
**Transfer-Encoding** A form of encoding transmitted to the user in the representation of an entity. Include: ‘chunked’, ‘compress’, ‘deflate’, ‘gzip’, ‘identity’. Transfer-Encoding: chunked fixed
Upgrade Requires the client to upgrade to another higher version protocol. Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/ X11 fixed
vary Inform the downstream proxy server how future request protocol headers should be matched to determine whether the cached response content can be used instead of re-requesting new content from the original server. `Vary: *` fixed
Via Tell the client of the proxy server by what route the current response is sent. Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3) fixed
Warning General warning that there may be an error in the entity content body. Warning: 199 Miscellaneous warning fixed
WWW-Authenticate Represents the authentication mode that should be used when requesting this entity. `WWW-Authenticate: Basic` fixed

6. What happened to entering the URL in the address bar

This is also a frequently asked interview question. So let’s take a look at what happens from the time you type in the URL to the time you respond.

  • First, you need to enter the URL you want to visit in your browser, as follows

You shouldn’t be able to access it, right

  • Then, the browser will check whether the domain name is cached by the local DNS based on the URL you enter. Different browsers have different Settings for DNS. If the browser caches the URL you want to access, it will return the IP address directly. If your URL is not cached, the browser will make a system call to query the hosthostsCheck whether the file has an IP address. If yes, the system returns the IP address. If not, a DNS query is issued to the network.

Let’s start with what DNS is. There are two ways to identify hosts on the Internet, by hostname and IP address. We like to remember by name, but routes in communication links prefer fixed-length, hierarchical IP addresses. So there is a need for a host name to IP address translation service, this service is provided by DNS. The full Name of DNS is Domain Name System. DNS is a distributed database implemented by hierarchical DNS servers. DNS runs on UDP and uses port 53.

DNS is a hierarchical database, and its main hierarchy is as follows

In addition, there is another important DNS server, which is the Local DNS server. Strictly speaking, the local DNS server does not belong to the above hierarchy, but the local DNS server is crucial. Each Internet Service Provider (ISP), such as an ISP in a residential area or an organization, has a local DNS server. When a host connects to an ISP, the ISP provides the IP address of a host, and the host has the IP address of one or more local DNS servers. By accessing network connections, users can easily determine the IP address of the DNS server. When a host sends a DNS request, the request is sent to the local DNS server, which acts as a proxy and forwards the request to the DNS server hierarchy.

If the local DNS server fails to find the destination IP address, the local DNS sends a DNS query to the root DNS server.

Note: DNS involves two types of query: Recursive query and Iteration query. “Computer Networks: The top-down Approach” unexpectedly does not give the difference between recursive query and iterative query, looked for information on the Internet probably understand the next.

If the root DNS server cannot tell the local DNS server which TOP-LEVEL DNS server to access next, a recursive query is used.

Iterative queries are used if the root DNS server can tell the DNS server which top-level DNS server it needs to access next.

After the root DNS server > top-level DNS server > authoritative DNS server, the authoritative server informs the local server of the destination IP address, and the local DNS server informs the user of the IP address to be accessed.

  • Step 3: The browser needs to establish a TCP connection with the target server, and the three-way handshake is required. For details about the handshake, see the preceding answer.
  • After the connection is established, the browser initiates a request to the target serverHTTP-GETRequests, including urls, use long connections by default after HTTP 1.1, requiring only one handshake to transfer data multiple times.
  • If the target server is a simple page, it returns directly. However, for some large sites, the site is often not directly returned to the host name of the page, but directly redirected. The status code returned is 301,302 redirection code starting with 3. After obtaining the redirection response, the browser finds the redirection address in the Location item of the response message, and the browser can access it again in the first step.
  • The browser then resends the request with the new URL and returns a status code of 200 OK, indicating that the server can respond to the request and return the packet.

7. How HTTPS works

We have described how HTTP works, and here is how HTTPS works. Because we know that HTTPS is not a new protocol, but rather

So, when we talk about HTTPS handshake, it’s actually SSL/TLS handshake.

TLS is an encryption protocol designed to secure communication over the Internet. A TLS handshake is the process of starting and using a TLS encrypted communication session. During the TLS handshake, communication parties on the Internet exchange information with each other, verify cipher suites, and exchange session keys.

A TLS handshake occurs every time a user navigates to a specific website over HTTPS and sends a request. In addition, TLS handshakes also occur whenever any other communication uses HTTPS, including API calls and DNS queries over HTTPS.

The TLS handshake process varies according to the type of key exchange algorithm used and the password suite supported by both parties. We discuss this process in terms of RSA asymmetric encryption. The whole TLS communication flow chart is as follows

  • Before communication, the HTTP three-way handshake is performed. After the handshake is complete, the TLS handshake is performed
  • ClientHello: The client sends a message to the serverhelloMessage to initiate the handshake process. Client support will be embedded in this messageTLS Version number (TLS1.0, TLS1.2, TLS1.3), client supported password suite, and a stringRandom number of client.
  • ServerHello: After the client sends the Hello message, the server sends a message containing the SSL certificate of the server, the password suite selected by the server, and a random number generated by the server.
  • Authentication: The client certificate authority authenticates the SSL certificate and sends itCertificateA packet containing a public key certificate. Finally the server sendsServerHelloDoneAs ahelloThe response to the request. The first part of the handshake is over.
  • Encryption stage: After the first phase of the handshake is complete, the client sendsClientKeyExchangeAs a response, this response contains a type calledThe premaster secretThe key string is the string encrypted using the public key certificate above. The client then sendsChangeCipherSpecTell the server to decrypt this using a private keypremaster secretThe client then sends the stringFinishedTell the server it’s done sending.

A Session key is a public key encrypted with a public key certificate.

  • Secure asymmetric encryption is realized: Then, the server sends it againChangeCipherSpec 和 FinishedTell the client that decryption is complete, thus achieving RSA asymmetric encryption.

8. Cookies are different from sessions

Cookies are small pieces of text that the server stores on the local machine and sends to the same server with each request. The Session mechanism is a server-side mechanism that uses a hash table like structure (and possibly hash tables) to store information. To put it simply, Cookies are stored on the client and sessions are stored on the server. When a program needs to create a Session for a client request, the server first checks whether the client request already contains a Session id (called the Session ID). If yes, it indicates that a session has been previously created for the client. The server retrieves the session based on the session ID and uses it (if no session ID is retrieved, a new session is created). If the client request does not contain the session ID, Create a session for this client and generate a session ID associated with this session. The value of the session ID should be a string that is neither repeated nor easy to find patterns to fake. This session ID will be returned to the client for saving in this response.

9.HTTP request mode

Seven methods for HTTP/1.1 GET Obtain resources POST Transfer entity body PUT Transfer file DELETE HEAD Obtain the packet HEAD. (HEAD is used to confirm the validity of the URI and the date and time of resource update, but does not return the packet body.) TRACE allows the server to loop back the previous request to the client. You can query how the sent data is processed and modified, which is easy to cause cross-site tracing attacks. CONNECT requires the tunnel protocol to CONNECT to the proxy

10. What is websocket

What is a Websocket? What are the advantages? Application? (1) HTTP has a defect, that is, the connection can only be initiated by the client, not the server. Websocket is a full duplex communication method to avoid such defects. (2) WebSocket is a protocol in HTML5, supporting persistent continuous, HTTP protocol does not support persistent connection. (3) WebSocket is based on Http protocol, or borrows Http protocol to complete part of the handshake, which is the same as Http in the handshake stage.

Other features include: (1) based on THE TCP protocol, the implementation of the server side is relatively easy. (2) It has good compatibility with HTTP protocol. The default ports are also 80 and 443, and the handshake phase uses HTTP protocol, so it is not easy to mask the handshake and can pass various HTTP proxy servers. (3) The data format is relatively light, the performance overhead is small, and the communication is efficient. (4) Can send text, can also send binary data. (5) There is no source restriction, and the client can communicate with any server. (6) The protocol identifier is WS (if encrypted, WSS), and the server URL is the URL.