HTTP

Hypertext transfer protocol

  • The request message

Let’s look at the format of the request message, the first is the request line, the request line includes method, URL, protocol text, method common GET/POST, URL is our request address, protocol text is generally HTTP1.1 version

Then look at the request header. The header fields are grouped together in the form of key: value, with multiple header field names forming the header field area

Then we have our entity body, which we don’t normally have in a GET request, but we usually have in a POST request

  • The response message

First you have the version, then you have the status code, and then you have the description of the status code, which we call the phrase, and then you have the same thing as the request message, which is the response message

HTTP request mode
  • GET

  • POST

  • HEAD

  • PUT

  • DELETE

  • OPTIONS

The difference between GET and POST

It is generally known that:

  • The GET request parameter is? Spliced to the end of the URL, the POST request parameter is inside the Body

  • The length of the GET parameter is limited to 2048 characters. The maximum length of the POST parameter is not limited

  • GET requests are less secure, POST requests are more secure

But from a semantic point of view, it looks like this:

  • GET: Obtains resources, which are secure, idempotent, and cacheable

  • POST: Processes resources that are insecure, non-idempotent, and non-cacheable

Corresponding interpretation

1, security: should not cause any state changes on the Server side, for example, we use GET requests to GET data on the Server side for several times, will not cause a state change on the Server, security requests include: GET, HEAD, OPTIONS

2, idempotent: the same request method to execute multiple times and execute once the effect is exactly the same, for example, we use GET request to the Server side for multiple times to obtain data, the effect of execution is exactly the same, here we need to pay attention to the effect of execution, idempotent requests include: GET, PUT, DELETE

3. Cacheability: Whether the request can be cached, we are generally in the process of initiating an HTTP request, the transmission link we are not sure, although it is really a TCP connection, but the network path in contact or through the gateway including some proxies to reach our Server, which will involve all aspects of the content, Some proxy servers often have caching, and this caching is an official specification, that is, can comply with or not comply with, most cases will comply with, so there will be corresponding cache in GET requests, cacheable requests include: GET, HEAD

Status code

Xx: 1 notice

2 xx: success

3XX: redirection

4XX: Client error

5XX: Server error

Connection establishment process

Three-way handshake

  • First, the client sends a SYN request to the server to establish a connection

  • After receiving the packet, the server sends a synchronous ACK packet to the client

  • After receiving the packet, the client sends an ACK packet to the server to complete the three-way handshake

Four times to wave

  • If the client initiates the active disconnection, the client sends a FIN termination packet to the server

  • The server sends an ACK message to the client, and the connection between the client and the server is disconnected. However, data may be transmitted from the server to the client. At an appropriate time, the server requests the client to disconnect

  • The server sends a FIN packet to the client to terminate the connection

  • Then, the client sends an acknowledgement packet to the server to complete the connection between the server and the client

The characteristics of HTTP
  • If there is no connection, the compensation scheme is HTTP persistent connection

  • Stateless, the compensation scheme is Cookie/Session

HTTPS and Network security

HTTPS = HTTP + SSL/TLS

HTTPS is based on the original HTTP, in the application layer below, transport layer above the inserted SSL/TLS protocol middle layer, for us to achieve a secure network mechanism, that is, HTTPS is secure HTTP

HTTPS connection establishment process
  • First, the client sends a packet to the server, which consists of three parts: the TLS version supported by the client, the encryption algorithm supported by the client, and a random number C

  • The server then returns a handshake message containing an agreed encryption algorithm, a random number S, and a server certificate

  • After receiving the message, the client first verifies the certificate and then assembles the session secret key. The session secret key is mainly assembled by the preceding random number C and S and a pre-master secret key

  • Then the client will encrypt and transmit the pre-master secret key through the public key of the server, and then the server will decrypt the pre-master secret key through the private key. Finally, the server will assemble the session secret key through the preceding random number C, random number S and the decrypted pre-master secret key

  • Then the client sends an encrypted handshake message to the server, and the server sends an encrypted handshake message to verify that the encryption is complete

TCP/UDP

Transport layer protocol

TCP: Transmission control protocol

UDP: user datagram protocol

UDP (User Datagram Protocol)

Features:

1. No connection

2. Try your best to deliver

3. Message-oriented, neither merge nor split

Features include:

1, the reuse

2, points to use

3. Error detection

TCP (Transmission Control Protocol)

Features:

1. Connection-oriented

2, reliable transmission (no error, no loss, no repetition, in order to arrive)

3. Byte oriented stream

4. Flow control

5. Congestion control

The DNS

For mapping domain names to IP addresses, DNS resolution requests use UDP datagrams and are in plaintext

DNS resolution query mode
  • Recursive query (layer by layer query)

  • Iterative query (return results to find the corresponding query)

DNS hijacking

When a client sends a domain name to a DNS server for a query, it will be eavesdropped because it is a UDP packet and has clear text. If a phishing server hijacks the query and returns a wrong IP address, you will end up with the wrong web page

Another point to note here is that DNS hijacking is completely unrelated to HTTP because DNS resolution takes place before the HTTP connection is established, and DNS resolution requests use UDP datagrams on port 53

So how do you solve DNS hijacking?

  • HttpDNS: a UDP datagram used to resolve DNS requests on port 53. The solution is to use HTTP to request DNS services on port 80 of the DNS server

  • Long connection: A long connection service (that is, a proxy server) is established between the client and the server. A long connection channel is established before the client and the proxy server. Then the proxy server and the client use Intranet private lines to resolve Intranet DNS requests

DNS resolution and forwarding problems

In a simple word, when a client sends a request, the DNS server may forward the request to another DNS server to save resources. Therefore, cross-network access may occur and the request may be slow

Session/Cookie

Compensation for HTTP protocol statelessness

Cookie

It is mainly used to record user status and distinguish users. The status is stored on the client. The Cookie sent by the client is in the Cookie header field of the HTTP request packet. The server sets the set-cookie header field of the HTTP response packet

Modify the Cookie
  • New cookies overwrite old cookies

  • Override rules: Name, path, and domain must be the same as the original Cookie

Delete the Cookie
  • New cookies overwrite old cookies

  • Override rules: Name, path, and domain must be the same as the original Cookie

  • Set Cookie expires = a past point in time, or maxAge = 0

How do I guarantee the security of cookies
  • The Cookie is encrypted

  • Carry cookies only over HTTPS

  • Set cookies to httpOnly to prevent cross-site scripting attacks

Session

It is also used to record user status and distinguish users; The state stored in the server Session relies on the Cookie mechanism

At this point, the basic content of iOS has come to an end for the time being. It may not be particularly detailed and there will be many flaws. Thank you for pointing out the problems in this article

IOS Discovery series

IOS Exploration: Event passing for UI views & View responses

IOS exploration: UI view stalling, frame dropping, and drawing principles

IOS Exploration: Basic data structures for Runtime

IOS Exploration: Runtime message forwarding and dynamic addition methods

IOS Exploration: Block parsing

IOS Exploration: The nature of RunLoop, data structures, and resident thread implementations

IOS Exploration: Web related