After talking about the three-way handshake and the four-way wave, I was asked to write the HTTP protocol code manually.

Recently, Afen’s colleagues have been preparing for interviews, and some good ones have received offers. After all, the epidemic has stabilized. However, when Afen was asked about the HTTP protocol during the telephone interview, she seemed a little numb. Why? Because the routine was too complicated, which caught Afen off guard.

[[335962]]

Interviewer: Do you understand TCP/IP protocol? To be honest, when Ah Fen heard this question, her first thought was, if I answer this question, there will definitely be a three-way handshake and four-way wave waiting for me, but I still have to answer it, so Ah Fen started to answer.

Ah Fan began to answer: Although TCP/IP protocols are mentioned together, they are actually two different protocols.

• IP protocol: The IP protocol is actually used to find addresses, and its corresponding layer is also the network layer, which can also be called the Internet layer. There is not much difference, just a different name.
• TCP protocol: TCP protocol is used to regulate transmission rules, which is different from IP protocol, and its corresponding layer is the transport layer. In this case, IP looks for addresses and leaves all transmission tasks to TCP. At this time, TCP appears and exists as a courier.

Interviewer: Then tell me what is a three-way handshake and what is a four-way wave.

1. Three-way handshake

Look at this picture. It comes from Baidu search, and there are all kinds of pictures on Baidu. When you see the picture at first, you will definitely not understand it, that is, you can only analyze it through the "line" of the symbol in the painting. In fact, this is only one aspect.

Then let's analyze what this picture means based on the picture. There are two serial numbers and three different flags in the picture, some of which are easily confused by uppercase and lowercase.

Serial number:

• seq: abbreviation of sequence number. Literally, it means sequence number. Yes, it is the sequence number. You have not translated it wrong. Believe in yourself. This seq represents the sequence number that is transmitted by itself. When TCP is transmitting, each byte in it will have a sequence number. When sending data, the first sequence number of the first data will be sent to the other party. This is the first step we have seen. The receiving side will check whether it is a complete data connection according to this sequence number. If your data is complete, then we can proceed to the next step. If your data is not complete, then resend it. In this way, the integrity of the data can be guaranteed not to be destroyed.

• ack: Note that this is lowercase ack, which is the abbreviation of acknoledgement number, and it represents the confirmation number, which should be distinguished from ACK (confirmation bit). The receiving end uses it to return the data information of the successful reception message to the sending end. At this time, its value means that I want to receive the next data packet now, and this value is the starting sequence number of the next data packet. The data before the sequence number represented by this ack has been received successfully.

• ACK: Confirmation bit. The confirmation bit comes. Only when ACK=1 will ack play its due role. When we initiate the request for the first time, because there is no received data that needs to be confirmed by us, the ACK at this time is 0. In the case of normal communication, ACK is 1.

• SYN: synchronization bit, and the role of the synchronization bit is to synchronize the sequence number when establishing a connection. When the connection is just started, if ACK is 0, then ack will not work. At this time, SYN says, you see, you can't do it without me, what use are you? When the receiving end receives the message with SYN=1, it will set ack to the value of the received seq+1. This is also what you see when you are reading the content provided by Baidu. Various seq=k, ACK=k+1, this is how it comes from. At this time, the value of ack is directly set according to SYN, so that you can transmit normally. Sometimes the interviewer will ask why SYN is 1 in the first two handshakes? In fact, this is because the ack of both parties transmitting data requires an initial value, otherwise how can you transmit and play.

• FIN: The termination bit is not fully reflected in this figure, but it can be fully reflected in the four waves. It is used to release the connection after the data transmission is completed.

So how do we tell the interviewer about this picture?

(1) First handshake (SYN=1, seq=x):

The client sends a packet with the TCP SYN flag set to 1, indicating the port of the server to which the client intends to connect, and the initial sequence number X, which is stored in the Sequence Number field of the packet header.

After sending, the client enters the SYN_SEND state.

(2) Second handshake (SYN=1, ACK=1, seq=y, ACKnum=x+1):

The server sends back an ACK packet. That is, the SYN flag and the ACK flag are both 1. The server selects its own ISN sequence number and puts it in the Seq field. At the same time, the Acknowledgement Number is set to the client's ISN plus 1, that is, X+1. After sending, the server enters the SYN_RCVD state.

(3) The third handshake (ACK=1, ACKnum=y+1)

The client sends an ACK packet again, with the SYN flag set to 0 and the ACK flag set to 1. It also adds 1 to the sequence number field of the ACK sent by the server, puts it in the confirmation field and sends it to the other party, and writes ISN + 1 in the data segment.

After sending, the client enters the ESTABLISHED state. When the server receives this packet, it also enters the ESTABLISHED state, and the TCP handshake ends.

If you say this, the interviewer may ask, this is too official, can you explain your understanding, then you can use a practical example to explain it to him.

Ah Fen: Ji Ding, hey, I'm Ah Fen, can you hear me?

Ji Ding: What are you arguing about? I heard you. Who else could I know besides you?

Ah Fan: You can hear me, but you didn't reply quickly. No wonder you don't have a girlfriend. Let's continue our conversation.

The three-way handshake process is commonly known as the three-way handshake, during which three conversations are conducted to determine whether the data transmission channels in both directions are normal.

2. Wave four times

So how do you answer the four waves?

(1) First wave (FIN=1, seq=x)

Assuming that the client wants to close the connection, the client sends a packet with the FIN flag set to 1, indicating that it has no data to send, but can still receive data.

After sending, the client enters the FIN_WAIT_1 state.

(2) Second wave (ACK=1, ACKnum=x+1)

The server confirms the client's FIN packet and sends a confirmation packet, indicating that it has received the client's request to close the connection, but is not yet ready to close the connection.

After sending, the server enters the CLOSE_WAIT state. After receiving the confirmation packet, the client enters the FIN_WAIT_2 state and waits for the server to close the connection.

(3) The third wave (FIN=1, seq=y)

When the server is ready to close the connection, it sends a connection end request to the client with FIN set to 1.

After sending, the server enters the LAST_ACK state and waits for the last ACK from the client.

(4) The fourth wave (ACK=1, ACKnum=y+1)

The client receives the close request from the server, sends a confirmation packet, and enters the TIME_WAIT state, waiting for a possible ACK packet requesting retransmission.

After receiving this confirmation packet, the server closes the connection and enters the CLOSED state.

After the client waits for a fixed period of time (two maximum segment lifecycles, 2MSL, 2 Maximum Segment Lifetime), it does not receive an ACK from the server, and thinks that the server has closed the connection normally, so it also closes the connection and enters the CLOSED state. After two retransmissions, it will retransmit until it times out. If there are too many, there will be a large number of half-connection blocking queues.

So how do you explain this to the interviewer in a simple way?

Ah Fen: Ji Ding, I have said everything I want to say, do you have anything else to say?

Ji Ding: I understand what you said, but don’t stop. I still have something to tell you. Please find me a girlfriend.

Ji Ding: xxxxx, I’m done.

Ah Fan, that’s enough, stop talking. Remember, I’m hanging up.

If the interviewer asks you this question and you answer it like this, with both the official explanation and your own understanding, then the question is almost answered.

The interviewer will obviously not let you off like this, and will definitely give you another surprise: Why three handshakes instead of four waves? Why not three?

This is because when the server is in the LISTEN state, after receiving the SYN message of the connection establishment request, it puts the ACK and SYN in one message and sends it to the client. When closing the connection, when receiving the other party's FIN message, it only means that the other party will no longer send data but can still receive data. Whether to close the data transmission channel now needs to be decided by the upper layer application. Therefore, the ACK and FIN of the server are generally sent separately. So at this time, the handshake is four times instead of three times.

So how do we write an HTTP protocol by hand? Here is the code:

 public class Server {
    public static void main(String[] args) throws Exception{
        ServerSocketChannel ssc = ServerSocketChannel .open();
        ssc.socket().bind(new InetSocketAddress(8080));
        ssc.configureBlocking(false);
        Selector selector = Selector .open();
        ssc.register(selector, SelectionKey.OP_ACCEPT);
 while (true){
            if (selector.select(3000)==0){
 continue;
 }
            Iterator <SelectionKey>​   keyIterator = selector .selectedKeys().iterator();
            while (keyIterator.hasNext()){
                SelectionKey key = keyIterator .next();
                new Thread(new HttpHandler(key)).run();
                keyIterator.remove();
 }
 }
 }
    private static class HttpHandler implements Runnable{ 
 
        private int bufferSize = 1024 ;
        private String localCharset = "UTF-8" ;
        private SelectionKey key;
        public HttpHandler(SelectionKey key){
 this.key =key;
 } 
 
        public void handleAccept()throws IOException{
            SocketChannel clientChannel = ((ServerSocketChannel)key.channel()).accept();
            clientChannel.configureBlocking(false);
            clientChannel.register(key.selector(),SelectionKey.OP_READ, ByteBuffer.allocate(bufferSize));
 } 
 
 @Override
 public void run() {
 try {
                if (key.isAcceptable()){
                    handleAccept();
 }
                if (key.isReadable()){
                    handleRead();
 }
            }catch (IOException e){
               e.printStackTrace();
 }
 } 
 
        public void handleRead() throws IOException{
            SocketChannel sc = (SocketChannel) key.channel();
            ByteBuffer buffer = (ByteBuffer) key.attachment();
 buffer.clear();
            if (sc.read(buffer)==-1){
 sc.close();
 }else {
                buffer.flip();
                String receiveString = Charset .forName(localCharset).newDecoder().decode(buffer).toString();
                String[] requestMessage = receiveString .split("\r\n");
                for (String s:requestMessage) {
                    System.out.println(s);
                    if (s.isEmpty()){
                        break;
 }
                    String[] firstLine = requestMessage [0].split(" ");
                    System.out.println();
                    System.out.println("Method:\t"+firstLine[0]);
                    System.out.println("url:\t"+firstLine[1]);
                    System.out.println("HTTP Version:\t"+firstLine[2]);
                    System.out.println(); 
 
                    StringBuffer sendString = new StringBuffer();
                    sendString.append("HTTP/1.1 200 OK\r\n");
                    sendString.append("Content-Type:text/html; charset = "+localCharset+" \r\n");
                    sendString.append("\r\n");
 sendString.append(" < html > < head > < title > Display message </ title > </ head > < body > ");
 sendString.append("The request message received is: < br /> ");
                    for (String s1:requestMessage) {
                        sendString.append(s1+" < br /> ");
 }
                    sendString.append(" </ body > </ html > ");
 buffer = ByteBuffer .wrap(sendString.toString().getBytes(localCharset));
                    sc.write(buffer);
                    sc.close();
 }
 } 
 
 } 
 
 }
 }

This is a simple implementation, just an implementation idea, not a real request processing. You should also pay attention to setting the Content-Type type, otherwise it is easy to go wrong, after all, the length is limited.