HTTP in iOS Just look at me

[[164463]]

This article is a contributed article.

HTTP is an old topic. In projects, we often need to send POST or GET requests to the server, but the understanding of HTTP should not be limited to this. A journey of a thousand miles begins with a single step. The further you want to go, the more thorough and comprehensive your understanding of the basic principles should be. It is not enough to just use ASIHttpRequest or AFNetWorking to pass a parameter and send a request. This article will take you to review HTTP in all aspects.

What you can gain from this article:

• The necessary elements of a complete HTTP request and response

• Differences between different HTTP versions

• The difference between HTTP, Socket, and TCP (easy to confuse)

1. HTTP Protocol

HTTP is essentially a protocol, the full name of which is Hypertext Transfer Protocol. As the name suggests, this protocol is used to specify the transmission rules between the client and the server, and the content transmitted is not limited to text (in fact, any type of data can be transmitted).

Figure 1.1 Transmission diagram.png

2. Content of HTTP request and response

What do we send when we send an HTTP request to the server?

Let's take a look at an example diagram of a POST request:

Figure 2.1 HTTP_POST request example.png

Note: This article uses Paw to simulate sending HTTP requests and uses Charles to capture packets. Select the "Request" and "Raw" options in Charles to see the entire content of the request.

The above example diagram actually contains several essential elements of an HTTP request: request line, request header (headerField), request body (body); similarly, the response also has status line, response header, and entity content. Next, we will expand on them one by one.

1. Request line

The request line contains the request method (Method), request uniform resource identifier (URI), and HTTP version number, as shown in the first line of Figure 2.1:

Figure 2.2 Request line.png

• The request method is the familiar POST, GET, HEAD, PUT, etc.

• URI is the part of the URL excluding the Host, which is the path of the resource on the local server.

• HTTP version number, the current mainstream version is 1.1 (adopted in 1999), and the latest version is 2.0 (released in May 2015). The differences between different versions will be expanded below.

2. Request header

The request header mainly stores additional information that the client wants to give to the server. The part in the frame below is the request header:

Figure 2.3 Request header.png

HTTP requests are represented by NSURLRequest and NSMutableRequest in iOS; HTTP responses are represented by NSHTTPURLResponse.

• Host: The network address of the target server

• Accept: Let the server know the type of data that the client can accept, such as text/html */*

• Content-Type: data type in the body, such as application/json; charset=UTF-8

• Accept-Language: The client's language environment, such as zh-cn

• Accept-Encoding: Data compression format supported by the client, such as gzip

• User-Agent: The client's software environment. We can change this field to the name of our own client, such as QQ music v1.11, such as browser Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_***ppleWebKit/600.8.9 (KHTML, like Gecko) Maxthon/4.5.2

• Connection: keep-alive, this field is available only from HTTP 1.1, and is used to tell the server that this is a persistent connection, "Please do not disconnect the TCP connection immediately after sending a response." More explanations about this field will be expanded in the following HTTP version introduction.

• Content-Length: The length of the body. If the body is empty, the value of this field is 0. This field is usually present in POST requests.

The body of a POST request may also be empty, so the Content-Length in POST may also be 0

• Cookie: User data stored locally to record user information. If any, it will be automatically attached.

It is worth mentioning that in iOS, when you send any request, whether you like it or not, NSURLRequest will automatically help you record the cookies set on the URL you visit. In iOS, it is represented by NSHTTPCookieStorage, which is a singleton.

 NSHTTPCookieStorage *cookieJar = [NSHTTPCookieStorage sharedHTTPCookieStorage];
 for (NSHTTPCookie *cookie in [cookieJar cookies]) {
 NSLog(@ "%@" , cookie);
 }

You can get all the cookies that are currently saved automatically. If you are interested in cookie operations, please refer to the article "Using cookies in http requests in iOS".

The above are the request headers that we often encounter in daily development. In fact, there are other fields, but they cannot be listed one by one due to space limitations. If you want to know all the request headers, please see the request header response header list here. How to set and add these fields in iOS? You can use the -[NSMutableURLRequest addValue: forHTTPHeaderField:] method. You can use -[NSURLRequest allHTTPHeaderFields] to get the fields that have been set for the current request. That is, we can customize the request headers we need through the above interface, but some fields cannot be changed. Let's take a look at the description of iOS:

Figure 2.4 iOS request header interface description.png

From the documentation, we can see that the Authorization Connection Host WWW-Authenticate header fields should not be changed in iOS.

3. Request body

The data that really needs to be sent to the server is the binary NSData type data of the uploaded file in the POST-multipart upload request. The request body is empty in the GET request. The request body is some form data in the ordinary POST request. In iOS, it is generally represented by the HTTPBody property of NSURLRequest and NSMutableURLRequest. To add the body, use -[NSMutableURLRequest setHTTPBody:].

4. Response status line

The status line is the status information returned by the server to the client, including the HTTP version number, status code, and the English name corresponding to the status code.

The following is a typical correct status line:

 HTTP/ 1.1   200 OK

This section needs to talk about error codes. In fact, HTTP request error codes can be roughly divided into the following categories based on the first digit from left to right of the error code:

1XX: Information prompt. It does not represent success or failure, but indicates a temporary response. For example, 100 means continue, and 101 means switch protocol.

2XX: Success

3XX: Redirection

4XX: Client error, most likely a problem with the client. For example, the friendly and lovely 404 means file not found, which means your URI is problematic and the directory on the server does not have the file. 414 URI is too long

5XX: Server error, such as 504 Gateway Timeout

You don't need to remember the error code. If an error occurs, just look up the corresponding error code. However, knowing the above classification will help you make a general judgment at the first time. At least you can know whether it is the server or the client.

5. Response header and response entity

This part is not much different from the request part. The fields of the response header are slightly different. The header field in the response header also moves to the request header response header list.

3. Introduction to HTTP Version

Here I simply divide HTTP versions into three categories: before 1.1, 1.1, and 2.0, and introduce the main differences between these three categories:

Before HTTP 1.1

• Persistent connections are not supported. Once the server responds to the client, the TCP connection is immediately disconnected.
• No request header or response header
• The client's previous and subsequent requests are synchronous. The next request must wait until the previous request gets a response from the server before it can be sent, which is somewhat similar to the synchronization mechanism of multi-threading.

HTTP 1.1 (mainstream version)

Compared with versions before 1.1, the following performance improvements have been made

• Add request headers and response headers
• Supports persistent connections. The client specifies the Connection as keep-alive in the request header to inform the server not to release the connection immediately after completing the response. HTTP is based on TCP. In HTTP 1.1, a TCP connection can handle multiple HTTP requests.
• Different client requests are asynchronous. The next request does not have to wait until the previous request comes back before being issued, but can be issued continuously, which is somewhat similar to multi-threaded asynchronous processing.

HTTP 2.0

In line with the principle of backward compatibility, 2.0 has all the features of 1.1 and uses the same API. However, 2.0 will only be used for https websites. Since it will take a long time for 2.0 to be popularized, it will not be expanded here. For more new features, please refer to this article.

Let's focus on a few changes made in the current 1.1 version. What are the benefits of supporting persistent connections? HTTP is based on TCP connections. If the connection is frequently started and disconnected, a lot of resources will be spent on TCP three-way handshakes and four handshakes, which is inefficient. Take requesting a web page as an example. We know that the image resources on an HTML page are not directly embedded in the web page, but only provide URLs. Images still need to send additional HTTP requests to download. A web page often requires multiple HTTP requests from the request to the final loading to the local. Before version 1.1, requesting a web page required multiple "handshake-handshake" processes, and each connection was independent of each other; while 1.1 and later versions only require at least one.

Next is request asynchrony. Its benefits can be found in multi-threaded asynchronous processing, which will not be expanded here.

The above characteristics can be represented by Figure 2.3:

Figure 3.1 Asynchronous request.jpg

We can see that: 1. N requests actually only establish one TCP connection, and 2. N requests are sent asynchronously continuously.

4. Differences between HTTP, Socket and TCP

These three concepts are often discussed and are also easy to be confused. Before reviewing, let's take a look at the position relationship of these three in the TCP/IP protocol suite:

Figure 4.1 Hierarchical relationship.png

HTTP is an application layer protocol, closer to the user end; TCP is a transport layer protocol; and socket is an abstract layer abstracted from the transport layer, essentially an interface. So essentially the three are easy to distinguish. Despite this, sometimes you may be confused, what is the difference between HTTP connection, TCP connection, and socket connection? Well, if the above diagram is not clear enough, let's continue reading.

1. The difference between TCP connection and HTTP connection

As mentioned above, HTTP is based on TCP. When a client sends an HTTP request to a server, the first step is to establish a TCP connection with the server, that is, a three-way handshake, "hello, hello". HTTP 1.1 supports persistent connections, that is, a TCP connection can send multiple HTTP requests.

Summary: HTTP is based on TCP

2. The difference between TCP connection and Socket connection

As we mentioned in Figure 4.1, the socket layer is just an abstract interface layer on the TCP/UDP transport layer, so a socket connection can be based on a connection or UDP. A socket connection based on the TCP protocol also needs to go through a three-way handshake to establish a connection, which is reliable; a socket connection based on the UDP protocol does not require a connection establishment process, but it will be sent regardless of whether the other party can receive it, which is unreliable. Most instant messaging IMs are the latter.

Summary: Socket is also based on TCP

3. The difference between HTTP connection and Socket connection

It is more meaningful to distinguish these two concepts. After all, TCP is invisible and intangible, while HTTP and Socket are real and can be used.

• HTTP is a short connection, while Socket (based on TCP protocol) is a long connection. Although HTTP1.1 has begun to support persistent connections, it still cannot guarantee that the connection will always be there. Once the TCP three-way handshake is established for a Socket connection, the connection status will remain unless one party actively disconnects.

• HTTP connection server cannot actively send messages, and Socket connection has restrictions on the order of sending requests between the two parties. This is very important because it will determine in which scenarios the two are suitable for application. HTTP adopts the "request-response" mechanism. Before the client sends a message to the server, the server cannot push a message to the client. It must be satisfied that the client sends the message first and the server replies later. The relationship between the two parties of the Socket connection is similar to peer2peer, and one party can shout to the other party at any time.

4. The question is: when should I use HTTP and when should I use socket

This question is raised very naturally. When you receive a network communication request with another party, you will naturally consider whether to use HTTP or Socket.

• When using HTTP: Both parties do not need to maintain an online connection all the time, such as client resource acquisition, file upload, etc.

• Socket usage: most instant messaging applications (QQ, WeChat), chat rooms, Apple APNs, etc.

In iOS, HTTP requests are usually made using native NSURLConnection, NSURLSession, or open source AFNetWorking (recommended), ASIHttpRequest (has stopped updating). For Socket connections, I often use CocoaAsyncSocket by robbiehanson (XMPPFramework is also created by him).

5. The end

The above is a review of HTTP-related concepts, which is suitable for both novices and experienced students to review together.

Welcome to leave a message, if there is anything wrong, please point it out.