Салимóненко Дмитрий Александрович

ЗАДАНИЕ 8: Простой прокси-сервер на ТСР-сокетах для LINUX (С/С++)

1. Вначале напишем клиент, который просто передаст вебсерверу заголовки браузера и выведет ответ в консоль

Сразу перейдем к делу и посмотрим программный код клиента (client.c) на языке С:

1. #include <sys/types.h>
2. #include <sys/socket.h>
3. #include <stdlib.h>
4. #include <stdio.h>
5. #include <unistd.h>
6. #include <fcntl.h>
7. #include <sys/stat.h>
8. #include <sys/types.h>
9. #include <netinet/in.h>
10. #include <arpa/inet.h>
11. #include<netdb.h> //hostent
12. #include <string.h>
13. char message[] = "GET / HTTP/1.1\r\nHost: 4846d.ru\r\nUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nConnection: keep-alive\r\nUpgrade-Insecure-Requests: 1\r\nCache-Control: max-age=0\r\n\r\n";
14. char buf1[1024];

15. int fs, fr;
16. int main()
17. {
18. int sock;
19. struct sockaddr_in addr;
20. sock = socket(AF_INET, SOCK_STREAM, 0);
21. if(sock < 0)
22. {
23. perror("socket");
24. exit(1);
25. }

26. //  Устанавливаем сокету параметр SO_REUSEADDR или SO_REUSEPORT, чтобы после прекращения работы программы порт не использовался системой и был готов для последующего использования. Полезно, когда программу нужно запустить вновь СРАЗУ после того, как она прекратила работу в предыдущий раз.
27. int reuse = 1;
28. if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (const char*)&reuse, sizeof(reuse)) < 0)
29. perror("setsockopt(SO_REUSEADDR) failed");
30. #ifdef SO_REUSEPORT
31. if (setsockopt(sock, SOL_SOCKET, SO_REUSEPORT, (const char*)&reuse, sizeof(reuse)) < 0)
32. perror("setsockopt(SO_REUSEPORT) failed");
33. #endif

34. addr.sin_family = AF_INET;
35. addr.sin_port = htons(80); //По умолчанию, сервер открывает, как правило, именно порт под номером 80 для службы НТТР. Да и браузер по умолчанию также обращается именно к этому порту при открытии страницы по протоколу НТТР.
36. // addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); // Это было раньше
37. struct hostent* hostSITE = gethostbyname("4846d.ru");
38. addr.sin_addr.s_addr = ((struct in_addr*)hostSITE->h_addr_list[0])->s_addr;

39. if(connect(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0)
40. {
41. perror("connect");
42. exit(2);
43. }
44. fs=send(sock, message, strlen(message)*sizeof(char), 0);
45. printf ("\n");

46. while((fr=recv(sock, buf1, sizeof(buf1), 0)) > 0)
47. {printf("%s", buf1);
48. printf ("\n!!!!!!!!!!!!!!!!!!!!!!!!!!!\n"); // Это так, для ориентации, ибо вывод html-страницы в консоль будет иметь немалый объем, легко запутаться
49. memset (buf1, 0, sizeof(buf1)); // Для чего это?
50. }
51. close(sock);
52. printf ("\n");
53. return 0;
54. }

Как видно, в целом, ничего особенного. Все это Вы уже, так или иначе, проходили, делая задания по сокетам.

В строчке 13 задаются (пока в виде символьного массива) заголовки браузера, предназначенные для открытия веб-страницы 4846d.ru. Вы, конечно, вполне можете попробовать пооткрывать и другую какую-нибудь страницу, в том числе, и с другого сайта. Кроме того, у меня в Ubuntu установлен Firefox 63. Если у Вас будет ДРУГОЙ браузер, заголовки. которые он отправляет для открытия страницы, будут, скорее всего, ДРУГИМИ. Как же их получить?

Получаем заголовки браузера

Можно, конечно, скопировать из консоли браузера. Нажимаем правой кнопкой мыши где-нибудь на веб-странице, затем «Исследовать элемент», «Сеть» и обновляем страницу. После чего можно будет посмотреть заголовки и запроса, и ответа. Но, они там будут, как минимум, не в том порядке, в каком браузер их посылает серверу.

Почему? Потому, что, к примеру, Firefox сортирует их по алфавиту. Чтобы пользователю было удобнее найти соответствующий заголовок. А передает их немного в другом порядке. Понятно, что веб-серверу это, как правило, без разницы; главное, чтобы нужные заголовки ВСЕ БЫЛИ, а уж в каком порядке – это уже детали (правда, некоторые веб-сервисы, типа Google, как раз обращают внимание на такие тонкости и по ним пытаются определить, из браузера ли делается запрос или он эмулирован). Но, все-таки, попытаемся притвориться браузером, чисто ради корректности, не более того. Для этого нам требуется где-то взять заголовки именно в том порядке, в котором их отправляет браузер. Для этого можно воспользоваться, скажем, заданием 5.

Следует скомпилировать приведенный в задании 5 код сервера (по ссылке), назвав его, к примеру, serv1.c (дальше будем называть эту программу локальным прокси-сервером). Затем, запустив его, в браузере откройте страницу

http://127.0.0.1:3425

После чего в браузере появятся заголовки его запроса (которые вернул обратно сервер), а также счетчик количества раз обновления страницы. Вот их-то мы и возьмем и скопируем с открытой в браузере веб-страницы, вставив в строчку 13 программы - клиента. Теперь осталось только вставить в нужных местах (где оканчивается очередной заголовок) переносы строк и переводы каретки, как требует спецификация протокола НТТР, т.е. символы \r\n. Не забудьте в конце вставить эти символы ДВАЖДЫ, так как необходимо послать веб-серверу пустую строку, чтобы он понял, что браузер более уже ничего посылать не будет и ждет ответа на свой запрос.

Возможно, пояснения еще требуют строчки 37, 38. Ранее, когда работали с локальным клиентом, IP-адрес указывали в виде строчки 36 (сейчас она закомментирована). Теперь же нам требуется адресоваться к хостингу (сайту), расположенному на веб-сервере. Поэтому используем структуру hostSITE  типа hostent.

Ну, а далее, как обычно, устанавливаем соединение при помощи функции connect() и посылаем заголовки веб-серверу (строчка 44). Обратите внимание, что мы здесь используем порт 80 (см. строчку 35), а не 3425, как обычно. Потому, что нам требуется обратиться к СТАНДАРТНОМУ порту, на котором у веб-сервера запущены служба НТТР. Для интереса, попробуйте вместо 80-го порта указать какой-либо другой, например, 3425. После запуска клиента в таком случае в консоли увидите через некоторое время знакомое «Connection refused». Вспомните, что так бывало, когда Вы пытались запустить листинг-клиент при незапущенном листинг-сервере. Так и здесь: то ли порт 3425 не открыт на сервере, содержащем страницу 4846d.ru, то ли открыт, но по протоколу HTTP он не работает и потому с нагим клиентом взаимодействовать не желает.

Да, здесь – как раз тот самый случай, когда нам придется использовать стандартный номер порта, который меньше, чем 1024.

После отправки заголовков заходим в цикл (строчка 46), в котором считываем все то, что сервер присылает нам на ТСР-порт под номером 80. Если сообщение веб-сервера будет большим (а там ведь его заголовки ответа, пустая строка и затем – ВСЯ веб-страница), итерации в цикле повторятся соответствующее количество раз. В конце каждой итерации полученные от сервера символы выводим на экран в консоль. Когда весь ответ сервера будет прочитан, закрываем сокет (строчка 51), выводим пустую строку и, вроде бы, прекращаем работу. НО: на самом деле, не все так просто.

Дело в том, что ТСР-соединения (при помощи которых реализуется передача сообщений в формате протокола НТТР) являются, что называется, «живучими». Т.е. они сразу не закрываются. Поэтому и наш клиент тоже сразу не закроется, а будет находиться в состоянии ожидания. Чтобы было понятнее, о чем идет речь, предварительно запустите утилиту tcpdump в следующем виде:

sudo tcpdump port 80 –A

Опция –А дает нам возможность выводить в консоль не только заголовки протоколов IP, ТСР, но и данные, полученные с веб-сервера, в ASCII-виде.

После чего запустите наш клиент.

Будет видно, что в консоли клиента появились заголовки ответа веб-сервера, затем, через пустую строку, HTML-код веб-страницы http://4846d.ru. После чего клиент останется в ждущем режиме.

Тогда как в консоли с запущенной tcpdump будут происходить многократные тройные ТСР-рукопожатия, затем - передачи и подтверждения данных. Также там появятся куски содержимого скачиваемой веб-страницы (код HTML). Обратите внимание, что наш клиент, как ни странно, отправляет запросы с портов под номерами типа таких: 42385 и т.п. Тогда как для веб-сервера используется порт 80 (который в данном случае будет обозначен, как .http).

Это означает, что, на самом деле, для того, чтобы обеспечить передачу заголовков веб-серверу (при помощи функции send() ) и соответствующий прием ответа от него (при помощи функции recv() ), операционная система (на уровне ядра, как говорится, за кулисами) реализует несколько дополнительных ТСР-соединений, которые используются для тройных рукопожатий, а также для контроля передачи данных. Для этого используются временные ТСР-порты с высокими номерами. Номера выбираются случайным образом.

Наша программа – клиент, использует, всего-то навсего, лишь ДВЕ строчки - для отправки запроса и для получения ответа. Система же - много чего делает для выполнения этих «всего лишь двух строчек».

Настраиваем браузер для работы с прокси-сервером

Чтобы полноценно использовать прокси-сервер в работе, необходимо обеспечить взаимодействие браузера с ним. Это можно сделать разными путями, открывая веб-страницы:

1. В виде http://localhost/4846d.ru,
2. В виде http://4846d.ru:3425,
3. С использованием прокси-настроек браузера.

Первый и второй пути (комбинированно) использовались в задании 5 (см. также выше). С этим может быть связана проблема, если открываемая веб-страница видоизменяет свое содержимое, например, при помощи AJAX-запросов. При которых, если не подключена CORS, будет применяться политика одного источника: одинаковые протокол, порт и домен. При нарушении хотя бы одного из этих требований запрос будет заблокирован браузером. К сожалению, так как AJAX-запрос выполняется средствами JS, будет проблематично переадресовать его на localhost и/или на другой порт (например, на порт 3425). Ибо в JS-коде, выполняющем AJAX, будут, скорее всего, прописаны совсем не эти домен и порт. Кстати, именно по этой причине многие прокси-серверы, имеющиеся в интернете, не дают возможность открытой веб-странице направлять AJAX-запросы. Ибо для их работоспособности (при использовании первого и второго путей) придется, по сути, писать собственный интерпретатор JS. А это задача - я Вам скажу...

По идее, можно, конечно, настроить переадресацию через iptables. Можно также добавить на открытую веб-страницы JS-код, который будет подменять нужным образом домен и порт AJAX-запроса. Также можно прислать от нашего клиента браузеру поддельный заголовок о разрешении технологии CORS. Кстати, это – достаточно интересная задача. Но, мы этим пока заниматься не будем, поступим проще: укажем браузеру принудительно соединяться с веб-серверами через локальный прокси-сервер. Для этого открываем в браузере

Настройки -> Параметры сети -> Настроить -> Ручная настройка прокси.

В НТТР-прокси указываем локальный IP-адрес: 127.0.0.1, порт: 3425. Ниже в «Не использовать прокси для», напротив, убираем запись, содержащую этот IP-адрес. Т.е. получится что-то примерно такое:

После чего – запускаем клиент, затем – пытаемся открыть в браузере страницу ЛЮБОГО сайта (главное, чтобы он открывался по протоколу НТТР, а не HTTPS, ведь мы настроили браузер на работу через прокси-сервер только для HTTP). В окне страницы увидим заголовки, отправленные браузером. Например, для страницы http://citforum.ru/programming/unix/sockets/ вместо ее содержимого (как было обычно) увидим:

• GET http://citforum.ru/programming/unix/sockets/ HTTP/1.1
• Host: citforum.ru
• User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
• Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
• Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
• Accept-Encoding: gzip, deflate
• Referer: https://www.google.com/
• Connection: keep-alive
• Upgrade-Insecure-Requests: 1
• Cache-Control: max-age=0

Т.е. локальный прокси-сервер (serv1.c), отвечая браузеру, вернул ему отправленные им (браузером) заголовки. Они же, кстати, появятся и в консоли, в которой запущен прокси-сервер. Выглядеть все это будет примерно так:

Обратите внимание, что URL запроса – http://www.4846d.ru, тогда как удаленный IP-адрес – 127.0.0.1:3425. Т.е. браузер считает, что страница 4846d.ru находится на локальном адресе и http-служба (протокол) открыла на прослушивание по этому адресу порт под номером 3425.

Далее, прокси-сервер ждет (не прекращая работать), но браузер ему ничего более не присылает. Почему? Потому, что он не получил надлежащего ответа: ведь прокси-сервер ему вернул его же заголовки, а не те, которые должен бы вернуть, будь он настоящим сервером. Поэтому браузер, по своей инициативе, запросил еще, разве что, фавиконку – и далее ничего не делает, ожидая заголовков ответа. Пока их нет, он считает, что сервер не ответил, а, следовательно, нет смысла делать следующие запросы (для скачивания файлов CSS, JS).

2. Выполняем прокси-сервер из кодов клиента и сервера

Итак, у нас с Вами получилось, с одной стороны, послать запрос программой клиентом на сервер и получить ответ; с другой стороны, получилось получить ответ заголовки, отсылаемые браузером – в целях соединения с веб-сервером. Осталось только соединить обе программы в одно целое и получить прокси-сервер. Вот что у меня получилось:

1. // Виртуальный прокси-сервер: посредник между браузером и веб-сайтами по протоколу НТТР  
2. #include <iostream>
3. #include <regex>
4. #include <cstring>
5. #include <sys/types.h>
6. #include <sys/socket.h>
7. #include <stdlib.h>
8. #include <stdio.h>
9. #include <unistd.h>
10. //#include <fcntl.h>
11. #include <sys/stat.h>
12. #include <sys/types.h>
13. #include <netinet/in.h>
14. #include <arpa/inet.h>
15. #include<netdb.h>  //hostent
16. //#include <string.h>

17. using namespace std;

18. // char message[] = "Server iteration: ";
19. // char message1[] = "GET /test.html HTTP/1.1\r\nHost: 4846d.ru\r\nUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nConnection: close\r\nUpgrade-Insecure-Requests: 1\r\nCache-Control: max-age=0\r\n\r\n";
20. unsigned int sz;
21. char *client(char*, char*);

22. int main()
23. {
24. int sock, listener;
25. struct sockaddr_in addr;
26. char buf[2048];
27. int bytes_read;
28. listener = socket(AF_INET, SOCK_STREAM, 0);
29. if(listener < 0)
30. {
31. perror("socket");
32. exit(1);
33. }

34. //  Устанавливаем сокету параметр SO_REUSEADDR или SO_REUSEPORT, чтобы после прекращения работы программы порт не использовался системой и был готов для последующего использования. Полезно, когда программу нужно запустить вновь СРАЗУ после того, как она прекратила работу в предыдущий раз.
35. int reuse = 1;
36. if (setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, (const char*)&reuse, sizeof(reuse)) < 0)
37. perror("setsockopt(SO_REUSEADDR) failed");
38. #ifdef SO_REUSEPORT
39. if (setsockopt(listener, SOL_SOCKET, SO_REUSEPORT, (const char*)&reuse, sizeof(reuse)) < 0)
40. perror("setsockopt(SO_REUSEPORT) failed");
41. #endif

42. addr.sin_family = AF_INET;
43. addr.sin_port = htons(3425);
44. addr.sin_addr.s_addr = htonl(INADDR_ANY);
45. if(bind(listener, (struct sockaddr *)&addr, sizeof(addr)) < 0)
46. {
47. perror("bind");
48. exit(2);
49. }
50. listen(listener, 1);

51. // Создаем новый временный файл  
52. FILE* fp; FILE* fp1;
53. if((fp=fopen("file_tmp", "wb"))==NULL)
54. { // Вначале уничтожаем этот файл (во избежание возможных остатков старого содержимого), если он есть, попутно проверяя, можно ли его создать и открыть
55. printf("Ошибка при открытии файла.\n");
56. exit(1);
57. }
58. fclose(fp);
59. // Создаем еще один новый временный файл
60. if((fp1=fopen("file1_tmp", "wb"))==NULL)
61. {
62. printf("Ошибка при открытии файла1.\n");
63. exit(1);
64. }
65. fclose(fp1);

66. int i =0;   // Счетчик итераций прокси-сервера
67. char *buf_changed; char *buf_from_site;

68. while(1)
69. {i++;
70. sz=sizeof(addr);
71. sock = accept(listener, (struct sockaddr *)&addr, &sz );
72. printf ("\nБраузерный запрос %d:\n", i);
73. if(sock < 0) {perror("accept"); exit(3);}

74. buf_changed = (char*)malloc(sizeof(char) * 10000); // Это опасно!
75. buf_from_site = (char*)malloc(sizeof(char) * 1000000); // Это опасно!

76. bytes_read = recv(sock, buf, sizeof(buf), 0);
77. if(bytes_read <= 0)
78. {printf("bytes_read= %d ;\n while(1) was broken\n", bytes_read);
79. break;}

80. printf("buf (headers from Brauzer):\n%s \n\n", buf);

81. // Подменяем заголовок, полученный от браузера: Connection: keep-alive -> Connection: close
82. string str = "", ex, str_to_change;
83. regex header("Connection:\\s*keep-alive"); // Что такое и для чего \\s*   ?

84. str_to_change = "Connection: close";
85. ex = regex_replace(buf, header, str_to_change);  // Подменяем заголовок
86. ex = ex.string::substr(0, (int)ex.find("\r\n\r\n")+4); // Берем только полезную часть сообщения, отбрасываем вспомогательные байты. Кстати, если компилировать при помощи не g++, а gcc, этих вспомогательных байтов не будет (правда, с gcc не получится, т.к. используем регулярные выражения и функцию find() ). Почему?... открытый вопрос. Равно как и то, что это за байты. Похоже, их добавляет веб-сервер в конец каждого фрагмента (чанка - chunk) сообщения. Но, почему это делается только если программа скомпилирована на g++? Непонятно.
87. buf_changed = (char*)ex.c_str(); // Преобразуем в char (т.к. С++)
88. printf("buf_changed (headers to web-server):\n__________\n%s \n__________\n", buf_changed);

89. fp=fopen("file_tmp", "ab"); // Записываем в файлы с добавлением, каждый раз начиная с конца данных, записанных в предыдущий раз
90. fp1=fopen("file1_tmp", "ab");   // Что означают параметры “ab” ?
91. fputs("\nChanged headers from brauzer (buf_changed):\n", fp);
92. fputs("\nChanged headers from brauzer (buf_changed):\n", fp1);

93. fwrite(buf_changed, strlen(buf_changed), 1, fp);
94. fwrite(buf_changed, strlen(buf_changed), 1, fp1);
95. fclose(fp);
96. fclose(fp1);

97. string host_str; // = "4846d.ru";
98. // Ищем в заголовках сообщения, которое будем отсылать веб-серверу, имя хоста
99. regex host_reg("Host:\\s*(.*?)\\r\\n");
100. std::cmatch cm;
101. std::regex_search(buf_changed, cm, host_reg);
102. // Удаляем из найденного фрагмента символы Host: и максимальное количество пробелов
103. regex host_reg1("Host:\\s*");
104. string cm_str = cm[0] ; // Берем самое первое совпадение (ибо последующие совпадения могут оказаться не в заголовках, а в теле запроса, к примеру)
105. char* cm_char = (char*)cm_str.c_str();
106. host_str = regex_replace(cm_char, host_reg1, ""); // Здесь и удаляем

107. cm_char =  (char*)host_str.c_str();
108. regex host_reg2("\\r|\\n");  
109. host_str = regex_replace(cm_char, host_reg2, "");  // А здесь удаляем перенос(ы) строк

110. char* host = (char*)host_str.c_str(); // Имя хоста (извлеченное из заголовков, посылаемых веб-серверу), например, 4846d.ru

111. // ***********************************************  
112. // Посылаем заголовки веб-серверу и считываем то, что он вернет в ответ
113. buf_from_site = client(buf_changed, host); // Функция client определена ниже

114. // Отсылаем то, что получили от веб-сервера, браузеру
115. send(sock, buf_from_site, strlen(buf_from_site), 0);

116. // free(buf_changed);
117. memset (buf, 0, sizeof(buf));

118. close(sock);
119. printf ("sosk  is closed.");  
120. } // Конец "бесконечного" цикла

121. printf ("free: buf_changed, buf_from_site... \n");  
122. free(buf_changed);
123. free(buf_from_site);
124. printf ("Stop.\n");
125. return 0;
126. }

127. // ******************************************************
128. char *client(char *message1, char* host) {
129. // char message1[] = "GET / HTTP/1.1\r\nHost: 4846d.ru\r\nUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nConnection: close\r\nUpgrade-Insecure-Requests: 1\r\nCache-Control: max-age=0\r\n\r\n";
130. char buf1[1024];
131. memset(buf1, 0, sizeof(buf1));

132. int fs, fr=0;
133. int sock1;
134. struct sockaddr_in addr;
135. sock1 = socket(AF_INET, SOCK_STREAM, 0);
136. if(sock1 < 0)
137. {
138. perror("socket");
139. exit(1);
140. }

141. //  Устанавливаем сокету параметр SO_REUSEADDR или SO_REUSEPORT, чтобы после прекращения работы программы порт не использовался системой и был готов для последующего использования. Полезно, когда программу нужно запустить вновь СРАЗУ после того, как она прекратила работу в предыдущий раз.
142. int reuse = 1;
143. if (setsockopt(sock1, SOL_SOCKET, SO_REUSEADDR, (const char*)&reuse, sizeof(reuse)) < 0)
144. perror("setsockopt(SO_REUSEADDR) failed");
145. #ifdef SO_REUSEPORT
146. if (setsockopt(sock1, SOL_SOCKET, SO_REUSEPORT, (const char*)&reuse, sizeof(reuse)) < 0)
147. perror("setsockopt(SO_REUSEPORT) failed");
148. #endif  

149. addr.sin_family = AF_INET;
150. addr.sin_port = htons(80); //По умолчанию, сервер открывает, как правило, именно порт под номером 80 для службы НТТР. Да и браузер по умолчанию также обращается именно к этому порту при открытии страницы по протоколу НТТР.
151. //addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);

152. // string host_str = "4846d.ru";  
153. // host =  (char*)host_str.c_str();

154. struct hostent* hostSITE = gethostbyname(host);
155. addr.sin_addr.s_addr = ((struct in_addr*)hostSITE->h_addr_list[0])->s_addr;

156. if(connect(sock1, (struct sockaddr *)&addr, sizeof(addr)) < 0)
157. {
158. perror("connect");
159. exit(2);
160. }
161. fs=send(sock1, message1, strlen(message1)*sizeof(char), 0);
162. printf (" BEGIN client: \n\n");
163. // char buf_all[1000000];
164. char *buf_all;
165. buf_all = (char*)malloc(1000000); // Выделяем память в куче (с некоторым запасом, это НЕоптимально), чтобы при выходе из этой функции возвращаемое ею значение не терялось. Если для buf_all не выделить динамическую память (если вместо этого, к примеру, инициализировать массив buf_all[100000]), она будет, в качестве локальной переменной, содержаться в стеке. При возврате из функции значение этой переменной  может быть потеряно (по истечению времени жизни локальных переменных).
166. //  char* buf_new;
167. //  buf_new = (char*)malloc(1000000);

168. FILE* fp; FILE* fp1;
169. // Записываем во временный файл  
170. fp=fopen("file_tmp", "ab"); // Записываем в файл с добавлением, каждый раз начиная с конца данных, записанных в предыдущий раз
171. fputs("\nServer response from site:\n", fp);
172. fp1=fopen("file1_tmp", "ab");
173. fputs("\nServer response from site:\n", fp1);

174. size_t fn=1;  

175. while((fr=recv(sock1, buf1, sizeof(buf1), 0)) > 0) // Почему нельзя сделать >=0 ?
176. { //  strcpy(buf_new, buf1);
177. buf_all = strncat(buf_all, buf1, fr); // Опасная функция! Т.к. переменная buf_all может неконтролируемо увеличиться!
178. printf("fr=%d  strlen(buf1)=%lu  strlen(buf_all)=%lu \n", fr, strlen(buf1), strlen(buf_all));

179. fn=fn+fr; // Счетчик числа полученных от веб-сервера байтов при очередном запросе
180. fwrite(buf1, fr, 1, fp1);
181. memset(buf1, 0, sizeof(buf1));
182. }

183. printf("Finally:\nfr=%d  strlen(buf1)=%lu  strlen(buf_all)=%lu \n", fr, strlen(buf1), strlen(buf_all));

184. fwrite(buf_all, fn, 1, fp);  // А теперь записываем весь ответ сервера целиком. Проверьте файлы file_tmp  и  file1_tmp - они могут различаться, в частности, при получении изображений. Почему?
185. fclose(fp);
186. fclose(fp1);

187. close(sock1);
188. printf (" FINISH client \n________________________________\n");
189. return buf_all;
190. }

С учетом вышесказанного, скомпилируйте программу в стандарте С++11:

g++ -o serv1 serv1.c -std=c++11

После чего в браузере (я использовал Firefox 63) откройте, например, страницу http://4846d.ru. Можно непосредственно ввести этот адрес в строке запроса браузера, можно перейти посылке откуда-нибудь или т.п., разницы нет. И – вот что увидим:

Браузер успешно загрузил, путем GET-запросов, все ресурсы, которые имеются на странице. Вначале он загрузил сам код html-страницы. Затем, проводя синтаксический ее анализ, он обнаруживал там ссылки для загрузки дополнительных ресурсов, в частности, JS-скриптов и CSS-файлов. Для этого он каждый раз инициировал ТСР-соединение (которое, согласно его прокси-настройкам, направлялось на IP-адрес 127.0.0.1:3425, попадая к нашей программе, так как она уже к этому времени открыла слушающий сокет на ТСР-порту 3425). Наш прокси-сервер, в свою очередь, принимал это соединение и выводил в консоль заголовки, полученные от браузера: buf (headers from brauzer).

Все бы хорошо, но, в целях ускорения взаимодействия с сервером, браузер пытается установить постоянное соединение, чтобы каждый раз его не устанавливать заново, для чего он посылает серверу заголовок

Connection: keep-alive.

Однако, заголовок-то этот попадет, вначале, нашему прокси-серверу. Который, соответственно, установит постоянное соединение. При этом цикл приема сообщение (строчки 161…168) не будет прерываться до тех пор, пока веб-сервер не разорвет соединение или пока не пришлет пустое сообщение (т.е. пока функция recv() в строчке 161 не получит нулевое или отрицательное значение). Однако, пока действует постоянное ТСР-соединение, веб-сервер, скорее всего, не будет этого делать.

Именно для этой цели мы в программе подменяем этот заголовок на

Connection: close

Это дает команду веб-серверу – разорвать соединение сразу после того, как будет передано ВСЁ сообщение. Поэтому для реализации последующих запросов браузер будет вынужден вновь устанавливать соединения (т.е. для каждого скачивания ресурса проходить процесс «тройного рукопожатия», а уже потом давать серверу запрос именно на скачивание конкретного ресурса).

Да, это очень неэкономично, в чем Вы, видимо, уже убедились, скачивая страницу через проски-сервер: скорость загрузки страницы ниже, чем обычно, раз в 3…5. Зато, программа является концептуально простой. Можно, разумеется, использовать здесь, например, неблокирующие сокеты (тогда возможно использование постоянного ТСР-соединения), но, это усложнит программу, хотя и сделает ее ближе к реальным схемам прокси-серверов.

Факт подмены заголовка виден на рисунке (выделено белым цветом). Именно для этого в программе использованы регулярные выражения (см. строчки 3, 84…86). Остальные заголовки неизменны, хотя, при желании, можно также легко изменить и их, перед тем, как передать веб-серверу – никто – ни браузер, ни веб-сервер ничего не заметят. Собственно, на то он и есть – прокси-сервер, чтобы давать возможность подобных замен (или подмен – как правильно-то).

Пояснения по программе прокси-сервера

Основная часть программы Вам, наверное, уже очевидна, если Вы внимательно отнеслись к предыдущим заданиям. Остановимся на некоторых не сразу очевидных аспектах. В программе создаются два файла с именами file_tmp и file1_tmp. Они создаются заново (см. строчки 52…66) при каждом очередном запросе (происходящем уже ПОСЛЕ того, как в очередной раз успешно произойдет «тройное рукопожатие») браузера к нашему прокси-серверу, т.е. при каждом скачивании того или иного ресурса (html-кода, JS-кода, CSS и т.д.). Т.е. в обоих файлах будут хранится, своего рода, логи запроса, где будут присутствовать:

• заголовки браузера, отосланные прокси-сервером на веб-сервер,
• заголовки веб-сервера, полученные прокси-сервером и переданные браузеру,
• содержимое ответов веб-сервера (т.е. содержимое скачиваемого ресурса).

При последующем запросе предыдущие логи будут удаляться, т.е. там будут храниться результаты только последнего взаимодействия браузера, прокси-сервера и веб-сервера.

Однако, запись в эти файлы происходит немного по-разному. В file_tmp запись производится в том числе, в рамках каждой итерации цикла в строчках 161…168. Тогда как в файл file1_tmp запись производится сразу «оптом», в частности, командой в строчке 170, уже после окончания работы цикла. А предварительная запись строчками 92…95 производится одинаково в обоих файлах. Указанное различие обуславливает, определенно, разные логи в файлах, в частности, когда речь идет о загружаемых изображениях (favicon.ico). Проанализируйте этот момент – почему так происходит.

Программа состоит из основной части (main() ) и одной функции (client() ). Функция предназначена для отправки заголовков браузера веб-серверу (строчка 147) и получения от него ответа (строчка 161). Так как ответ может быть достаточно большим, несмотря на фрагментированность (заголовок Transfer-Encoding: chunked), поэтому целесообразно производить считывание в цикле. Повторимся, если бы мы не подменили заголовок Connection: keep-alive на Connection: close, даже после того, как веб-сервер окончил передачу очередного сообщения (т.е. передал бы все его фрагменты – чанки), цикл в строчке 161 так и оставался бы в ждущем режиме (именно так и обстоит дело в программе client.c, см. выше). Ибо использован обычный, т.е. блокирующий сокет. А вследствие подмены, как только передача сообщения прекращена, веб-сервер посылает нам признак окончания сообщения и цикл в строчке 161 прекращается.

В итоге, выводим некоторую информацию в консоль, записываем в файлы полученный от веб-сервера ответ и возвращаемся в основную программу.

Итак, будучи вызванной из строчки 100, функция вернет нам заголовки, возвращенные веб-сервером и содержимое отдаваемого им ресурса, и все это запишется в переменную (точнее, в массив) buf_from_site.

После чего осталось лишь передать браузеру то, что мы получили в конце очередного запроса к веб-серверу, что и делается в строчке 102. При этом браузер считает, что все данные пришли в соответствии с его ожиданиями (которые он обозначил в своих заголовках). Однако, сервер вернул заголовок Connection: close (в ответ на подмененный нами соответствующий заголовок), что означает, что после получения очередного запроса браузеру, если он захочет скачать с сервера что-то еще, потребуется вновь устанавливать ТСР-соединение. Вот, наверное, и все.

Наконец, посмотрим, для примера, заголовки первого запроса, в процессе которого скачивался код-html с веб-сервера:

Видны заголовки ответа (вверху) и запроса (внизу). Видим также, что браузер предложил Connection: keep-alive, однако веб-сервер вернул Connection: close (кстати, это – не нарушает правили HTTP-протокола). В качестве удаленного адреса фигурирует 127.0.0.1:3425. Иными словами, именно этот IP-адрес соответствует доменному имени и URL запроса, в связи с прокси-настройками браузера.