Як записати HTTP-сервер?


17

Як видно з назви, я хотів би написати сервер HTTP. Моє запитання таке, як це зробити? Я знаю, це звучить ДУЖЕ загально і занадто "високий рівень", але є метод для мого божевілля. Відповідь на це питання повинна бути, я вважаю, мовою агностиком; сенс, незалежно від того, якою мовою я користуюся (наприклад, C, C ++, Java тощо), відповідь має бути однаковою. Я маю загальне уявлення про те, як це має працювати:

  1. Відкрийте розетку на порту 80.
  2. Зачекайте, коли клієнт зробить запит.
  3. Прочитайте запит (тобто, ця людина хоче сторінки "contact-us.html").
  4. Знайдіть і прочитайте "contact-us.html".
  5. Надішліть заголовок html, а потім надішліть вміст "contact-us.html"
  6. Зроблено

Як я вже сказав, я вважаю, що це процес, але я не впевнений на 100%. Це підводить мене до основи мого питання. Як або де людина дізнається цю інформацію?

Що робити, якщо я не хотів писати лише сервер HTTP, що робити, якщо я хотів написати FTP-сервер, сервер чату, переглядач зображень тощо? Як людина дізнається точні кроки / процес, необхідний для створення робочого HTTP-сервера?

Співробітник розповів мені про html-заголовок, тому я б ніколи не знав цього без нього. Він також сказав щось про передачу кожного запиту в нову нитку. Чи є якась велика книга про те, як все працює? Чи є інструкція про те, що потрібно, щоб бути HTTP-сервером?

Я спробував googling "як працює сервер HTTP", але єдині відповіді, які я міг знайти, були спрямовані на середнього Джо, а не на людину, яка хоче запрограмувати сервер HTTP.


12
RFC2616 повинен містити для вас усі деталі з дрібною крупою протоколу HTTP. RFC959 - те саме, що і для FTP.
— Майк

3
Альтернативно (або додатково) подивіться, як реалізуються існуючі прості сервери HTTP. Більше одного, це повинно дати вам уявлення про те, які структури мають сенс.
— Майкл Боргвардт

Майкл Боргвардт - Я б це зробив, але у мене є тенденція копіювати те, що я бачив, переглядаючи інший код. Я сподівався зайти в цю чистоту, побачити, чи зможу я це зробити самостійно без "обману".
— Брайан

Ваша фраза пошуку в Інтернеті неправильна, вона орієнтована на користувачів, тому Ви отримуєте середні речі Джо. Використовуйте: "як розробити сервер HTTP", натомість він краще відображає те, що ви шукаєте. Я просто спробував це в Google і отримав повну сторінку посилань, які пояснюють цей матеріал
— gnat

розглянемо перегляд інших реалізацій, наприклад, apache tomcat. Це, мабуть, робить більше, ніж ви хочете, але це продемонструє одну техніку вирішення проблеми.
— DwB

Відповіді:


19

Використовуйте RFC2616 , Лука!

Ви читаєте RFC 2616 на HTTP / 1.1 , і переходите до цього.

Це був насправді проект на моєму третьому курсі інженерної школи, і це майже опис проекту.

Інструменти

Ваші інструменти:

  • основні роботи в мережі (управління сокетами, прив'язка, розуміння адрес),
  • добре розуміння потоків вводу / виводу,
  • багато терпіння, щоб отримати деякі тінисті частини RFC (mime-тип - це весело).

Веселі міркування

Що варто врахувати для додаткової забави:

  • архітектура плагінів для додавання підтримки CGI / mod,
  • файли конфігурації для, ну, багато речей,
  • багато експериментів щодо оптимізації передач,
  • багато експериментів, щоб дізнатися, як керувати завантаженням з точки зору процесора та пам’яті, а також вибрати модель відправки (великий цикл жирної рівномірності, одиночне прийняття відправки, багатопотокове, багатопроцесовий тощо).

Весело. Це дуже класна річ.

Інші (простіші) пропозиції

  • FTP- клієнт / сервер (в основному RFC959, але є і більш старі версії, а також деякі розширення)
  • Клієнт / сервер IRC (переважно RFC1459 , але є розширення)

З ними легше вирішуватись спочатку, і їх RFC набагато легше засвоюється (ну, IRC має деякі дивні частини, але FTP - це досить зрозуміло).

Вибір мови

Звичайно, деякі деталі реалізації будуть сильно залежати від мови та стеку, який ви використовуєте для її реалізації. Я підійшов до всього, що в С, але я впевнений, що це може бути цікаво так само, як і в інших мовах (добре, може, не так весело, але все-таки весело).


Так, мені довелося це робити ще в школі. Це дивно весело і дає вам більше вдячності веб-серверам "промислової міцності".
— Евікатос

Отримання права на реалізацію протоколу - одна частина; архітектура сервера - це ще ...
— tdammers

@tdammers: RFC дуже гарні, якщо ви будете слідувати за ними, у вас вже є пристойний план голими кістками. У вас ще багато місця для вашого архітектурного дизайну, але це досить хороша та директивна специфікація.
— haylem

@haylem: так і ні. Реалізація специфікації дає вам індивідуального працівника, але вам все одно потрібно вбудовувати цього працівника в більшу картину - як ви дбаєте про обробку одночасних запитів? Як ви надаєте корисний контент? Де ви тримаєте державу?
— tdammers

@tdammers: я: You still have lots of room for your architecture design, but it's a pretty good and directive spec.ви: yes and no. Я думаю, ми вже звузили, ніж RFC не все. І я думаю, що до ОП належить виявити ці речі, а не безпосередньо вказати на них більше, ніж те, що я вже робив у розділах "зайві міркування" та інші речі. Це частина веселощів.
— haylem

2

Кожен із протоколів, що використовуються в Інтернеті, вказаний в одному або декількох публічних документах під назвою RFC. Усі поточні RFC можна знайти на веб- сайті http://www.rfc-editor.org/ , який також має гідну функцію пошуку.

Наприклад, протокол HTTP (версія 1.1) вказаний в RFC2616, а протокол FTP вказаний в RFC959 .

Що стосується специфікації, то, на мою думку, RFC дуже добре читаються.


Я справді плутаюся з цим RFC. Чи будуть вони коли-небудь оновлювати HTTP RFC? У наведеній вище відповіді є коментар, в якому йдеться In 2014, RFC2616 was replaced by multiple RFCs (7230-7237).. Отже, як знайти оновлені RFC, якщо вони є? Чи потрібно перевірити Obsoleted byсписок?
— SkrewEverything

@SkrewEverything: RFC не оновлюються, але їх замінюють новішими RFC. Ви дійсно знайдете новіші, перейшовши за посиланнями "Застаріле".
— Барт ван Інген Шенау
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.