ການນໍາສະເຫນີ

ເຕົາປະຕິກອນ I/O (ສາຍດຽວ ວົງເຫດການ) ເປັນ​ຮູບ​ແບບ​ສໍາ​ລັບ​ການ​ຂຽນ​ຊອບ​ແວ​ໂຫຼດ​ສູງ​, ນໍາ​ໃຊ້​ໃນ​ວິ​ທີ​ແກ້​ໄຂ​ທີ່​ນິ​ຍົມ​ຫຼາຍ​:

• Nodejs
• Tor
• ລະບົບສາຍສົ່ງ
• chromium
• ບັນທຶກໄວ້
• ...

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະເບິ່ງ ins ແລະ outs ຂອງເຄື່ອງປະຕິກອນ I / O ແລະວິທີການເຮັດວຽກ, ຂຽນການປະຕິບັດໃນລະຫັດຫນ້ອຍກວ່າ 200 ເສັ້ນ, ແລະເຮັດໃຫ້ຂະບວນການ HTTP server ງ່າຍດາຍຫຼາຍກວ່າ 40 ລ້ານຄໍາຮ້ອງຂໍ / ນາທີ.

ຄໍາອະທິຖານ

• ບົດຄວາມຖືກຂຽນເພື່ອຊ່ວຍໃຫ້ເຂົ້າໃຈເຖິງການເຮັດວຽກຂອງເຄື່ອງປະຕິກອນ I/O, ແລະດັ່ງນັ້ນຈິ່ງເຂົ້າໃຈຄວາມສ່ຽງໃນເວລາທີ່ໃຊ້ມັນ.
• ຄວາມຮູ້ພື້ນຖານແມ່ນຈໍາເປັນເພື່ອເຂົ້າໃຈບົດຄວາມ. ພາສາ C ແລະປະສົບການບາງຢ່າງໃນການພັດທະນາແອັບພລິເຄຊັນເຄືອຂ່າຍ.
• ລະ​ຫັດ​ທັງ​ຫມົດ​ແມ່ນ​ຂຽນ​ເປັນ​ພາ​ສາ C ຢ່າງ​ເຂັ້ມ​ງວດ​ອີງ​ຕາມ (ຂໍ້ຄວນລະວັງ: PDF ຍາວ) ກັບມາດຕະຖານ C11 ສໍາລັບ Linux ແລະມີຢູ່ໃນ GitHub.

ເປັນຫຍັງຈຶ່ງຈໍາເປັນ?

ດ້ວຍຄວາມນິຍົມຂອງອິນເຕີເນັດທີ່ເພີ່ມຂຶ້ນ, ເຄື່ອງແມ່ຂ່າຍເວັບເລີ່ມຈໍາເປັນຕ້ອງຈັດການກັບການເຊື່ອມຕໍ່ຈໍານວນຫລາຍພ້ອມໆກັນ, ແລະດັ່ງນັ້ນສອງວິທີໄດ້ຖືກພະຍາຍາມ: ການສະກັດ I / O ໃນຈໍານວນຫລາຍຂອງ OS threads ແລະ I / O ທີ່ບໍ່ປິດກັ້ນປະສົມປະສານກັບ. ລະບົບການແຈ້ງເຕືອນເຫດການ, ເອີ້ນວ່າ "ຕົວເລືອກລະບົບ" (epol/ຄິວ/IOCP/etc).

ວິທີການທໍາອິດກ່ຽວຂ້ອງກັບການສ້າງກະທູ້ OS ໃຫມ່ສໍາລັບແຕ່ລະການເຊື່ອມຕໍ່ຂາເຂົ້າ. ຂໍ້ເສຍຂອງມັນແມ່ນການປັບຂະຫນາດທີ່ບໍ່ດີ: ລະບົບປະຕິບັດການຈະຕ້ອງປະຕິບັດຫຼາຍຢ່າງ ການຫັນປ່ຽນສະພາບການ и ໂທລະບົບ. ພວກເຂົາເປັນການດໍາເນີນງານລາຄາແພງແລະສາມາດນໍາໄປສູ່ການຂາດ RAM ຟຣີທີ່ມີຈໍານວນການເຊື່ອມຕໍ່ທີ່ຫນ້າປະທັບໃຈ.

ສະບັບດັດແກ້ໄດ້ເນັ້ນໃສ່ ຈໍານວນຄົງທີ່ຂອງກະທູ້ (thread pool), ດັ່ງນັ້ນການປ້ອງກັນລະບົບຈາກການຍົກເລີກການປະຕິບັດ, ແຕ່ໃນເວລາດຽວກັນແນະນໍາບັນຫາໃຫມ່: ຖ້າ thread pool ປະຈຸບັນຖືກບລັອກໂດຍການດໍາເນີນການອ່ານຍາວ, ຫຼັງຈາກນັ້ນ socket ອື່ນໆທີ່ມີແລ້ວສາມາດຮັບຂໍ້ມູນຈະບໍ່ສາມາດ. ເຮັດແນວນັ້ນ.

ວິທີການທີສອງໃຊ້ ລະບົບການແຈ້ງເຕືອນເຫດການ (ຕົວເລືອກລະບົບ) ສະໜອງໃຫ້ໂດຍ OS. ບົດ​ຄວາມ​ນີ້​ປຶກ​ສາ​ຫາ​ລື​ປະ​ເພດ​ທົ່ວ​ໄປ​ຂອງ​ຕົວ​ເລືອກ​ລະ​ບົບ​, ໂດຍ​ອີງ​ໃສ່​ການ​ແຈ້ງ​ເຕືອນ (ເຫດ​ການ​, ການ​ແຈ້ງ​ການ​) ກ່ຽວ​ກັບ​ການ​ກຽມ​ພ້ອມ​ສໍາ​ລັບ​ການ​ດໍາ​ເນີນ​ງານ I/O​, ແທນ​ທີ່​ຈະ​ເປັນ​. ແຈ້ງການກ່ຽວກັບການສໍາເລັດຂອງເຂົາເຈົ້າ. ຕົວຢ່າງທີ່ງ່າຍດາຍຂອງການນໍາໃຊ້ຂອງມັນສາມາດຖືກສະແດງໂດຍແຜນວາດຕັນຕໍ່ໄປນີ້:

ຄວາມແຕກຕ່າງລະຫວ່າງວິທີການເຫຼົ່ານີ້ແມ່ນມີດັ່ງນີ້:

• ການຂັດຂວາງການດໍາເນີນການ I/O ໂຈະ ກະແສຜູ້ໃຊ້ ຈົນກ່ວາຈົນກ່ວາ OS ຖືກຕ້ອງ defragments ຂາເຂົ້າ ຊຸດ IP ກັບ byte stream (TCP, ການ​ຮັບ​ຂໍ້​ມູນ​) ຫຼື​ຈະ​ບໍ່​ມີ​ພື້ນ​ທີ່​ພຽງ​ພໍ​ທີ່​ມີ​ຢູ່​ໃນ​ການ​ບັນ​ທຶກ​ການ​ຂຽນ​ພາຍ​ໃນ​ສໍາ​ລັບ​ການ​ສົ່ງ​ຕໍ່​ມາ​ໂດຍ​ຜ່ານ​ການ NIC (ສົ່ງຂໍ້ມູນ).
• ຕົວເລືອກລະບົບ ລ່ວງ​ເວ​ລາ ແຈ້ງໂຄງການວ່າ OS ແລ້ວ ຊຸດ IP defragmented (TCP, ການຮັບຂໍ້ມູນ) ຫຼືພື້ນທີ່ພຽງພໍໃນ buffers ຂຽນພາຍໃນ ແລ້ວ ສາມາດໃຊ້ໄດ້ (ສົ່ງຂໍ້ມູນ).

ເພື່ອສະຫຼຸບມັນ, ການຈອງກະທູ້ OS ສໍາລັບແຕ່ລະ I / O ແມ່ນເສຍພະລັງງານຄອມພິວເຕີ້, ເພາະວ່າໃນຄວາມເປັນຈິງ, ກະທູ້ບໍ່ໄດ້ເຮັດວຽກທີ່ເປັນປະໂຫຍດ (ເພາະສະນັ້ນຄໍາສັບ. "ຊອບແວຂັດຂວາງ"). ຕົວເລືອກລະບົບແກ້ໄຂບັນຫານີ້, ອະນຸຍາດໃຫ້ໂຄງການຜູ້ໃຊ້ສາມາດນໍາໃຊ້ຊັບພະຍາກອນ CPU ໄດ້ຫຼາຍທາງດ້ານເສດຖະກິດ.

ຮູບແບບເຄື່ອງປະຕິກອນ I/O

ເຄື່ອງປະຕິກອນ I/O ເຮັດໜ້າທີ່ເປັນຊັ້ນລະຫວ່າງຕົວເລືອກລະບົບ ແລະລະຫັດຜູ້ໃຊ້. ຫຼັກການຂອງການດໍາເນີນງານຂອງມັນຖືກອະທິບາຍໂດຍແຜນວາດຕັນຕໍ່ໄປນີ້:

• ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າເຫດການຫນຶ່ງແມ່ນການແຈ້ງເຕືອນວ່າເຕົ້າສຽບທີ່ແນ່ນອນສາມາດດໍາເນີນການ I/O ທີ່ບໍ່ສະກັດກັ້ນ.
• ຕົວຈັດການເຫດການແມ່ນຫນ້າທີ່ເອີ້ນໂດຍເຄື່ອງປະຕິກອນ I/O ເມື່ອໄດ້ຮັບເຫດການ, ເຊິ່ງຫຼັງຈາກນັ້ນດໍາເນີນການ I/O ທີ່ບໍ່ສະກັດກັ້ນ.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າເຄື່ອງປະຕິກອນ I / O ແມ່ນຕາມຄໍານິຍາມດຽວກະທູ້, ແຕ່ບໍ່ມີຫຍັງຢຸດແນວຄວາມຄິດຈາກການນໍາໃຊ້ໃນສະພາບແວດລ້ອມຫຼາຍ threaded ໃນອັດຕາສ່ວນຂອງ 1 thread: ເຕົາປະຕິກອນ 1, ດັ່ງນັ້ນການ recycle cores CPU ທັງຫມົດ.

Реализация

ພວກເຮົາຈະວາງການໂຕ້ຕອບສາທາລະນະໃນໄຟລ໌ reactor.h, ແລະການປະຕິບັດ - ໃນ reactor.c. reactor.h ຈະ​ປະ​ກອບ​ດ້ວຍ​ການ​ປະ​ກາດ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ສະແດງການປະກາດໃນ reactor.h

typedef struct reactor Reactor;

/*
 * Указатель на функцию, которая будет вызываться I/O реактором при поступлении
 * события от системного селектора.
 */
typedef void (*Callback)(void *arg, int fd, uint32_t events);

/*
 * Возвращает `NULL` в случае ошибки, не-`NULL` указатель на `Reactor` в
 * противном случае.
 */
Reactor *reactor_new(void);

/*
 * Освобождает системный селектор, все зарегистрированные сокеты в данный момент
 * времени и сам I/O реактор.
 *
 * Следующие функции возвращают -1 в случае ошибки, 0 в случае успеха.
 */
int reactor_destroy(Reactor *reactor);

int reactor_register(const Reactor *reactor, int fd, uint32_t interest,
                     Callback callback, void *callback_arg);
int reactor_deregister(const Reactor *reactor, int fd);
int reactor_reregister(const Reactor *reactor, int fd, uint32_t interest,
                       Callback callback, void *callback_arg);

/*
 * Запускает цикл событий с тайм-аутом `timeout`.
 *
 * Эта функция передаст управление вызывающему коду если отведённое время вышло
 * или/и при отсутствии зарегистрированных сокетов.
 */
int reactor_run(const Reactor *reactor, time_t timeout);

ໂຄງສ້າງເຄື່ອງປະຕິກອນ I/O ປະກອບດ້ວຍ ຕົວອະທິບາຍໄຟລ໌ ໂຕເລືອກ epol и ຕາຕະລາງ hash GHashTable, ເຊິ່ງແຜນທີ່ແຕ່ລະຊັອກເກັດໄປຫາ CallbackData (ໂຄງສ້າງຂອງຕົວຈັດການເຫດການແລະການໂຕ້ຖຽງຂອງຜູ້ໃຊ້ສໍາລັບມັນ).

ສະແດງ Reactor ແລະ CallbackData

struct reactor {
    int epoll_fd;
    GHashTable *table; // (int, CallbackData)
};

typedef struct {
    Callback callback;
    void *arg;
} CallbackData;

ກະລຸນາສັງເກດວ່າພວກເຮົາໄດ້ເປີດໃຊ້ຄວາມສາມາດໃນການຈັດການ ປະເພດບໍ່ຄົບຖ້ວນ ອີງຕາມດັດຊະນີ. IN reactor.h ພວກເຮົາປະກາດໂຄງສ້າງ reactor, ແລະໃນ reactor.c ພວກເຮົາກໍານົດມັນ, ດັ່ງນັ້ນການປ້ອງກັນຜູ້ໃຊ້ຈາກການປ່ຽນແປງທົ່ງນາຂອງຕົນຢ່າງຊັດເຈນ. ນີ້ແມ່ນຫນຶ່ງໃນຮູບແບບ ເຊື່ອງຂໍ້ມູນ, ເຊິ່ງ succinctly fits ເຂົ້າໄປໃນ C semantics.

ຟັງຊັນ reactor_register, reactor_deregister и reactor_reregister ປັບປຸງບັນຊີລາຍຊື່ຂອງເຕົ້າຮັບຄວາມສົນໃຈແລະຕົວຈັດການເຫດການທີ່ສອດຄ້ອງກັນຢູ່ໃນຕົວເລືອກລະບົບແລະຕາຕະລາງ hash.

ສະແດງຫນ້າທີ່ລົງທະບຽນ

#define REACTOR_CTL(reactor, op, fd, interest)                                 
    if (epoll_ctl(reactor->epoll_fd, op, fd,                                   
                  &(struct epoll_event){.events = interest,                    
                                        .data = {.fd = fd}}) == -1) {          
        perror("epoll_ctl");                                                   
        return -1;                                                             
    }

int reactor_register(const Reactor *reactor, int fd, uint32_t interest,
                     Callback callback, void *callback_arg) {
    REACTOR_CTL(reactor, EPOLL_CTL_ADD, fd, interest)
    g_hash_table_insert(reactor->table, int_in_heap(fd),
                        callback_data_new(callback, callback_arg));
    return 0;
}

int reactor_deregister(const Reactor *reactor, int fd) {
    REACTOR_CTL(reactor, EPOLL_CTL_DEL, fd, 0)
    g_hash_table_remove(reactor->table, &fd);
    return 0;
}

int reactor_reregister(const Reactor *reactor, int fd, uint32_t interest,
                       Callback callback, void *callback_arg) {
    REACTOR_CTL(reactor, EPOLL_CTL_MOD, fd, interest)
    g_hash_table_insert(reactor->table, int_in_heap(fd),
                        callback_data_new(callback, callback_arg));
    return 0;
}

ຫຼັງຈາກເຄື່ອງປະຕິກອນ I/O ໄດ້ຂັດຂວາງເຫດການກັບຕົວອະທິບາຍ fd, ມັນໂທຫາຕົວຈັດການເຫດການທີ່ສອດຄ້ອງກັນ, ທີ່ມັນຜ່ານ fd, ຫນ້າກາກນ້ອຍ ເຫດການທີ່ສ້າງຂຶ້ນແລະຕົວຊີ້ຜູ້ໃຊ້ໄປຫາ void.

ສະແດງຟັງຊັນ reactor_run()

int reactor_run(const Reactor *reactor, time_t timeout) {
    int result;
    struct epoll_event *events;
    if ((events = calloc(MAX_EVENTS, sizeof(*events))) == NULL)
        abort();

    time_t start = time(NULL);

    while (true) {
        time_t passed = time(NULL) - start;
        int nfds =
            epoll_wait(reactor->epoll_fd, events, MAX_EVENTS, timeout - passed);

        switch (nfds) {
        // Ошибка
        case -1:
            perror("epoll_wait");
            result = -1;
            goto cleanup;
        // Время вышло
        case 0:
            result = 0;
            goto cleanup;
        // Успешная операция
        default:
            // Вызвать обработчиков событий
            for (int i = 0; i < nfds; i++) {
                int fd = events[i].data.fd;

                CallbackData *callback =
                    g_hash_table_lookup(reactor->table, &fd);
                callback->callback(callback->arg, fd, events[i].events);
            }
        }
    }

cleanup:
    free(events);
    return result;
}

ເພື່ອສະຫຼຸບ, ລະບົບຕ່ອງໂສ້ການເອີ້ນຟັງຊັນໃນລະຫັດຜູ້ໃຊ້ຈະມີຮູບແບບດັ່ງຕໍ່ໄປນີ້:

ເຊີບເວີກະທູ້ດຽວ

ເພື່ອທົດສອບເຄື່ອງປະຕິກອນ I/O ພາຍໃຕ້ການໂຫຼດສູງ, ພວກເຮົາຈະຂຽນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ HTTP ແບບງ່າຍດາຍທີ່ຕອບສະຫນອງຄໍາຮ້ອງຂໍໃດໆທີ່ມີຮູບພາບ.

ການອ້າງອີງໄວຕໍ່ກັບໂປຣໂຕຄໍ HTTP

HTTP - ນີ້ແມ່ນພິທີການ ລະດັບຄໍາຮ້ອງສະຫມັກ, ຕົ້ນຕໍແມ່ນໃຊ້ສໍາລັບການໂຕ້ຕອບກັບເຊີບເວີ-ບຣາວເຊີ.

HTTP ສາມາດຖືກນໍາໃຊ້ໄດ້ງ່າຍກວ່າ ການຂົນສົ່ງ ພິທີການ TCP, ການສົ່ງແລະຮັບຂໍ້ຄວາມໃນຮູບແບບທີ່ລະບຸໄວ້ ສະເພາະ.

ຮູບແບບການຮ້ອງຂໍ

<КОМАНДА> <URI> <ВЕРСИЯ HTTP>CRLF
<ЗАГОЛОВОК 1>CRLF
<ЗАГОЛОВОК 2>CRLF
<ЗАГОЛОВОК N>CRLF CRLF
<ДАННЫЕ>

• CRLF ແມ່ນລໍາດັບຂອງສອງລັກສະນະ: r и n, ແຍກແຖວທໍາອິດຂອງຄໍາຮ້ອງຂໍ, ຫົວແລະຂໍ້ມູນ.
• <КОМАНДА> - ຫນຶ່ງ​ໃນ CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE. ຕົວທ່ອງເວັບຈະສົ່ງຄໍາສັ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ GET, ຊຶ່ງຫມາຍຄວາມວ່າ "ສົ່ງເນື້ອຫາຂອງໄຟລ໌ໃຫ້ຂ້ອຍ."
• <URI> - ຕົວລະບຸຊັບພະຍາກອນທີ່ເປັນເອກະພາບ. ຕົວຢ່າງ, ຖ້າ URI = /index.html, ຫຼັງຈາກນັ້ນລູກຄ້າຮ້ອງຂໍເອົາຫນ້າຕົ້ນຕໍຂອງເວັບໄຊທ໌.
• <ВЕРСИЯ HTTP> — ສະບັບຂອງ HTTP protocol ໃນຮູບແບບ HTTP/X.Y. ສະບັບທີ່ໃຊ້ທົ່ວໄປທີ່ສຸດໃນມື້ນີ້ແມ່ນ HTTP/1.1.
• <ЗАГОЛОВОК N> ແມ່ນຄູ່ຄີ-ຄ່າໃນຮູບແບບ <КЛЮЧ>: <ЗНАЧЕНИЕ>, ຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍສໍາລັບການວິເຄາະຕື່ມອີກ.
• <ДАННЫЕ> — ຂໍ້​ມູນ​ທີ່​ຕ້ອງ​ການ​ໂດຍ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ໃນ​ການ​ດໍາ​ເນີນ​ການ​. ເລື້ອຍໆມັນງ່າຍດາຍ JSON ຫຼືຮູບແບບອື່ນໆ.

ຮູບ​ແບບ​ການ​ຕອບ​ສະ​ຫນອງ​

<ВЕРСИЯ HTTP> <КОД СТАТУСА> <ОПИСАНИЕ СТАТУСА>CRLF
<ЗАГОЛОВОК 1>CRLF
<ЗАГОЛОВОК 2>CRLF
<ЗАГОЛОВОК N>CRLF CRLF
<ДАННЫЕ>

• <КОД СТАТУСА> ແມ່ນຕົວເລກທີ່ສະແດງຜົນຂອງການປະຕິບັດງານ. ເຊີບເວີຂອງພວກເຮົາຈະສົ່ງຄືນສະຖານະ 200 ສະເໝີ (ການດຳເນີນການທີ່ສຳເລັດ).
• <ОПИСАНИЕ СТАТУСА> — ຕົວ​ແທນ​ສາຍ​ຂອງ​ລະ​ຫັດ​ສະ​ຖາ​ນະ​ພາບ​. ສໍາລັບລະຫັດສະຖານະ 200 ນີ້ແມ່ນ OK.
• <ЗАГОЛОВОК N> — ສ່ວນຫົວຂອງຮູບແບບດຽວກັນກັບຢູ່ໃນຄໍາຮ້ອງຂໍ. ພວກເຮົາຈະສົ່ງຄືນຫົວຂໍ້ Content-Length (ຂະຫນາດໄຟລ໌) ແລະ Content-Type: text/html (ປະເພດຂໍ້ມູນຄືນ).
• <ДАННЫЕ> — ຂໍ້​ມູນ​ທີ່​ຮ້ອງ​ຂໍ​ໂດຍ​ຜູ້​ໃຊ້​. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນເສັ້ນທາງໄປສູ່ຮູບພາບໃນ HTML.

ເອກະສານ http_server.c (ເຊີບເວີ threaded ດຽວ) ປະກອບມີໄຟລ໌ common.h, ເຊິ່ງປະກອບດ້ວຍ prototypes ຫນ້າທີ່ດັ່ງຕໍ່ໄປນີ້:

ສະແດງຕົວແບບຟັງຊັນໃນ common.h

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов принять новое соединение.
 */
static void on_accept(void *arg, int fd, uint32_t events);

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов отправить HTTP ответ.
 */
static void on_send(void *arg, int fd, uint32_t events);

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов принять часть HTTP запроса.
 */
static void on_recv(void *arg, int fd, uint32_t events);

/*
 * Переводит входящее соединение в неблокирующий режим.
 */
static void set_nonblocking(int fd);

/*
 * Печатает переданные аргументы в stderr и выходит из процесса с
 * кодом `EXIT_FAILURE`.
 */
static noreturn void fail(const char *format, ...);

/*
 * Возвращает файловый дескриптор сокета, способного принимать новые
 * TCP соединения.
 */
static int new_server(bool reuse_port);

ມະຫາພາກທີ່ມີປະໂຫຍດຍັງຖືກອະທິບາຍ SAFE_CALL() ແລະຫນ້າທີ່ຖືກກໍານົດ fail(). macro ປຽບທຽບຄ່າຂອງການສະແດງຜົນກັບຄວາມຜິດພາດ, ແລະຖ້າເງື່ອນໄຂເປັນຈິງ, ໂທຫາຟັງຊັນ. fail():

#define SAFE_CALL(call, error)                                                 
    do {                                                                       
        if ((call) == error) {                                                   
            fail("%s", #call);                                                 
        }                                                                      
    } while (false)

ການທໍາງານຂອງ fail() ພິມ​ການ​ໂຕ້​ຖຽງ​ທີ່​ຜ່ານ​ໄປ​ທີ່ terminal (ເຊັ່ນ​:​ printf()) ແລະຢຸດໂຄງການດ້ວຍລະຫັດ EXIT_FAILURE:

static noreturn void fail(const char *format, ...) {
    va_list args;
    va_start(args, format);
    vfprintf(stderr, format, args);
    va_end(args);
    fprintf(stderr, ": %sn", strerror(errno));
    exit(EXIT_FAILURE);
}

ການທໍາງານຂອງ new_server() ສົ່ງຄືນຕົວອະທິບາຍໄຟລ໌ຂອງຊັອກເກັດ "ເຊີບເວີ" ທີ່ສ້າງຂຶ້ນໂດຍການໂທລະບົບ socket(), bind() и listen() ແລະມີຄວາມສາມາດໃນການຍອມຮັບການເຊື່ອມຕໍ່ຂາເຂົ້າໃນຮູບແບບທີ່ບໍ່ມີການຂັດຂວາງ.

ສະແດງຟັງຊັນ new_server()

static int new_server(bool reuse_port) {
    int fd;
    SAFE_CALL((fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP)),
              -1);

    if (reuse_port) {
        SAFE_CALL(
            setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &(int){1}, sizeof(int)),
            -1);
    }

    struct sockaddr_in addr = {.sin_family = AF_INET,
                               .sin_port = htons(SERVER_PORT),
                               .sin_addr = {.s_addr = inet_addr(SERVER_IPV4)},
                               .sin_zero = {0}};

    SAFE_CALL(bind(fd, (struct sockaddr *)&addr, sizeof(addr)), -1);
    SAFE_CALL(listen(fd, SERVER_BACKLOG), -1);
    return fd;
}

• ໃຫ້ສັງເກດວ່າເຕົ້າສຽບໄດ້ຖືກສ້າງຂື້ນໃນເບື້ອງຕົ້ນໃນໂຫມດບໍ່ຖືກບລັອກໂດຍໃຊ້ທຸງ SOCK_NONBLOCKດັ່ງນັ້ນໃນຫນ້າທີ່ on_accept() (ອ່ານເພີ່ມເຕີມ) ການໂທລະບົບ accept() ບໍ່ໄດ້ຢຸດການປະຕິບັດກະທູ້.
• ຖ້າຫາກວ່າ reuse_port ເທົ່າກັນ true, ຫຼັງຈາກນັ້ນຟັງຊັນນີ້ຈະ configure socket ກັບທາງເລືອກ SO_REUSEPORT ຜ່ານ setsockopt()ເພື່ອໃຊ້ພອດດຽວກັນໃນສະພາບແວດລ້ອມຫຼາຍກະທູ້ (ເບິ່ງພາກ "ເຄື່ອງແມ່ຂ່າຍຫຼາຍກະທູ້").

ຕົວຈັດການເຫດການ on_accept() ເອີ້ນວ່າຫຼັງຈາກ OS ສ້າງເຫດການ EPOLLIN, ໃນກໍລະນີນີ້ຫມາຍຄວາມວ່າການເຊື່ອມຕໍ່ໃຫມ່ສາມາດຍອມຮັບໄດ້. on_accept() ຍອມຮັບການເຊື່ອມຕໍ່ໃຫມ່, ປ່ຽນມັນໄປສູ່ໂຫມດບໍ່ບລັອກແລະລົງທະບຽນກັບຕົວຈັດການເຫດການ on_recv() ໃນເຕົາປະຕິກອນ I/O.

ສະແດງຟັງຊັນ on_accept().

static void on_accept(void *arg, int fd, uint32_t events) {
    int incoming_conn;
    SAFE_CALL((incoming_conn = accept(fd, NULL, NULL)), -1);
    set_nonblocking(incoming_conn);
    SAFE_CALL(reactor_register(reactor, incoming_conn, EPOLLIN, on_recv,
                               request_buffer_new()),
              -1);
}

ຕົວຈັດການເຫດການ on_recv() ເອີ້ນວ່າຫຼັງຈາກ OS ສ້າງເຫດການ EPOLLIN, ໃນກໍລະນີນີ້ຫມາຍຄວາມວ່າການເຊື່ອມຕໍ່ທີ່ລົງທະບຽນ on_accept(), ພ້ອມທີ່ຈະຮັບຂໍ້ມູນ.

on_recv() ອ່ານຂໍ້ມູນຈາກການເຊື່ອມຕໍ່ຈົນກ່ວາການຮ້ອງຂໍ HTTP ໄດ້ຮັບຢ່າງສົມບູນ, ຫຼັງຈາກນັ້ນມັນລົງທະບຽນຕົວຈັດການ on_send() ເພື່ອສົ່ງຄໍາຕອບ HTTP. ຖ້າລູກຄ້າທໍາລາຍການເຊື່ອມຕໍ່, ເຕົ້າຮັບຖືກຍົກເລີກການລົງທະບຽນແລະປິດໂດຍໃຊ້ close().

ສະແດງຟັງຊັນ on_recv()

static void on_recv(void *arg, int fd, uint32_t events) {
    RequestBuffer *buffer = arg;

    // Принимаем входные данные до тех пор, что recv возвратит 0 или ошибку
    ssize_t nread;
    while ((nread = recv(fd, buffer->data + buffer->size,
                         REQUEST_BUFFER_CAPACITY - buffer->size, 0)) > 0)
        buffer->size += nread;

    // Клиент оборвал соединение
    if (nread == 0) {
        SAFE_CALL(reactor_deregister(reactor, fd), -1);
        SAFE_CALL(close(fd), -1);
        request_buffer_destroy(buffer);
        return;
    }

    // read вернул ошибку, отличную от ошибки, при которой вызов заблокирует
    // поток
    if (errno != EAGAIN && errno != EWOULDBLOCK) {
        request_buffer_destroy(buffer);
        fail("read");
    }

    // Получен полный HTTP запрос от клиента. Теперь регистрируем обработчика
    // событий для отправки данных
    if (request_buffer_is_complete(buffer)) {
        request_buffer_clear(buffer);
        SAFE_CALL(reactor_reregister(reactor, fd, EPOLLOUT, on_send, buffer),
                  -1);
    }
}

ຕົວຈັດການເຫດການ on_send() ເອີ້ນວ່າຫຼັງຈາກ OS ສ້າງເຫດການ EPOLLOUT, ຫມາຍຄວາມວ່າການເຊື່ອມຕໍ່ໄດ້ລົງທະບຽນ on_recv(), ພ້ອມທີ່ຈະສົ່ງຂໍ້ມູນ. ຟັງຊັນນີ້ສົ່ງຄໍາຕອບ HTTP ທີ່ມີ HTML ທີ່ມີຮູບພາບໄປຫາລູກຄ້າແລະຫຼັງຈາກນັ້ນປ່ຽນຕົວຈັດການເຫດການກັບຄືນໄປບ່ອນ on_recv().

ສະແດງຟັງຊັນ on_send().

static void on_send(void *arg, int fd, uint32_t events) {
    const char *content = "<img "
                          "src="https://habrastorage.org/webt/oh/wl/23/"
                          "ohwl23va3b-dioerobq_mbx4xaw.jpeg">";
    char response[1024];
    sprintf(response,
            "HTTP/1.1 200 OK" CRLF "Content-Length: %zd" CRLF "Content-Type: "
            "text/html" DOUBLE_CRLF "%s",
            strlen(content), content);

    SAFE_CALL(send(fd, response, strlen(response), 0), -1);
    SAFE_CALL(reactor_reregister(reactor, fd, EPOLLIN, on_recv, arg), -1);
}

ແລະສຸດທ້າຍ, ໃນໄຟລ໌ http_server.c, ໃນຫນ້າທີ່ main() ພວກເຮົາສ້າງເຕົາປະຕິກອນ I/O ໂດຍໃຊ້ reactor_new(), ສ້າງຊັອກເກັດເຊີຟເວີແລະລົງທະບຽນມັນ, ເລີ່ມຕົ້ນເຄື່ອງປະຕິກອນໂດຍໃຊ້ reactor_run() ສໍາລັບຫນຶ່ງນາທີແນ່ນອນ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາປ່ອຍຊັບພະຍາກອນແລະອອກຈາກໂຄງການ.

ສະແດງ http_server.c

#include "reactor.h"

static Reactor *reactor;

#include "common.h"

int main(void) {
    SAFE_CALL((reactor = reactor_new()), NULL);
    SAFE_CALL(
        reactor_register(reactor, new_server(false), EPOLLIN, on_accept, NULL),
        -1);
    SAFE_CALL(reactor_run(reactor, SERVER_TIMEOUT_MILLIS), -1);
    SAFE_CALL(reactor_destroy(reactor), -1);
}

ໃຫ້ກວດເບິ່ງວ່າທຸກຢ່າງເຮັດວຽກຕາມທີ່ຄາດໄວ້. ການລວບລວມ (chmod a+x compile.sh && ./compile.sh ໃນຮາກໂຄງການ) ແລະເປີດເຄື່ອງແມ່ຂ່າຍທີ່ຂຽນດ້ວຍຕົນເອງ, ເປີດ http://127.0.0.1:18470 ໃນ browser ແລະເບິ່ງສິ່ງທີ່ພວກເຮົາຄາດຫວັງ:

ການວັດແທກປະສິດທິພາບ

ສະແດງສະເພາະລົດຂອງຂ້ອຍ

$ screenfetch
 MMMMMMMMMMMMMMMMMMMMMMMMMmds+.        OS: Mint 19.1 tessa
 MMm----::-://////////////oymNMd+`     Kernel: x86_64 Linux 4.15.0-20-generic
 MMd      /++                -sNMd:    Uptime: 2h 34m
 MMNso/`  dMM    `.::-. .-::.` .hMN:   Packages: 2217
 ddddMMh  dMM   :hNMNMNhNMNMNh: `NMm   Shell: bash 4.4.20
     NMm  dMM  .NMN/-+MMM+-/NMN` dMM   Resolution: 1920x1080
     NMm  dMM  -MMm  `MMM   dMM. dMM   DE: Cinnamon 4.0.10
     NMm  dMM  -MMm  `MMM   dMM. dMM   WM: Muffin
     NMm  dMM  .mmd  `mmm   yMM. dMM   WM Theme: Mint-Y-Dark (Mint-Y)
     NMm  dMM`  ..`   ...   ydm. dMM   GTK Theme: Mint-Y [GTK2/3]
     hMM- +MMd/-------...-:sdds  dMM   Icon Theme: Mint-Y
     -NMm- :hNMNNNmdddddddddy/`  dMM   Font: Noto Sans 9
      -dMNs-``-::::-------.``    dMM   CPU: Intel Core i7-6700 @ 8x 4GHz [52.0°C]
       `/dMNmy+/:-------------:/yMMM   GPU: NV136
          ./ydNMMMMMMMMMMMMMMMMMMMMM   RAM: 2544MiB / 7926MiB
             .MMMMMMMMMMMMMMMMMMM

ໃຫ້ວັດແທກປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍທີ່ມີກະທູ້ດຽວ. ໃຫ້ເປີດສອງ terminals: ໃນຫນຶ່ງພວກເຮົາຈະດໍາເນີນການ ./http_server, ໃນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ - wrk. ຫຼັງຈາກນາທີ, ສະຖິຕິຕໍ່ໄປນີ້ຈະສະແດງຢູ່ໃນສະຖານີທີສອງ:

$ wrk -c100 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   493.52us   76.70us  17.31ms   89.57%
    Req/Sec    24.37k     1.81k   29.34k    68.13%
  11657769 requests in 1.00m, 1.60GB read
Requests/sec: 193974.70
Transfer/sec:     27.19MB

ເຊີບເວີກະທູ້ດຽວຂອງພວກເຮົາສາມາດປະມວນຜົນຫຼາຍກວ່າ 11 ລ້ານຄໍາຮ້ອງຂໍຕໍ່ນາທີທີ່ມາຈາກ 100 ການເຊື່ອມຕໍ່. ບໍ່ແມ່ນຜົນໄດ້ຮັບທີ່ບໍ່ດີ, ແຕ່ສາມາດປັບປຸງໄດ້ບໍ?

ເຊີບເວີ Multithreaded

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ເຄື່ອງປະຕິກອນ I/O ສາມາດຖືກສ້າງຂື້ນໃນກະທູ້ແຍກຕ່າງຫາກ, ດັ່ງນັ້ນການນໍາໃຊ້ແກນ CPU ທັງຫມົດ. ໃຫ້ພວກເຮົາເອົາວິທີນີ້ໄປປະຕິບັດ:

ສະແດງ http_server_multithreaded.c

#include "reactor.h"

static Reactor *reactor;
#pragma omp threadprivate(reactor)

#include "common.h"

int main(void) {
#pragma omp parallel
    {
        SAFE_CALL((reactor = reactor_new()), NULL);
        SAFE_CALL(reactor_register(reactor, new_server(true), EPOLLIN,
                                   on_accept, NULL),
                  -1);
        SAFE_CALL(reactor_run(reactor, SERVER_TIMEOUT_MILLIS), -1);
        SAFE_CALL(reactor_destroy(reactor), -1);
    }
}

ໃນປັດຈຸບັນທຸກກະທູ້ ເປັນເຈົ້າຂອງຂອງຕົນເອງ ເຕົາປະຕິກອນ:

static Reactor *reactor;
#pragma omp threadprivate(reactor)

ກະລຸນາສັງເກດວ່າການໂຕ້ຖຽງຟັງຊັນ new_server() ຢືນ true. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາມອບຫມາຍທາງເລືອກໃຫ້ກັບເຕົ້າຮັບເຄື່ອງແມ່ຂ່າຍ SO_REUSEPORTເພື່ອໃຊ້ມັນໃນສະພາບແວດລ້ອມຫຼາຍກະທູ້. ທ່ານສາມາດອ່ານລາຍລະອຽດເພີ່ມເຕີມ ທີ່ນີ້.

ໄລຍະທີສອງ

ຕອນນີ້ໃຫ້ພວກເຮົາວັດແທກປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍຫຼາຍກະທູ້:

$ wrk -c100 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.14ms    2.53ms  40.73ms   89.98%
    Req/Sec    79.98k    18.07k  154.64k    78.65%
  38208400 requests in 1.00m, 5.23GB read
Requests/sec: 635876.41
Transfer/sec:     89.14MB

ຈໍາ​ນວນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ປະ​ຕິ​ບັດ​ໃນ 1 ນາ​ທີ​ເພີ່ມ​ຂຶ້ນ ~ 3.28 ເທົ່າ​! ແຕ່ພວກເຮົາມີພຽງແຕ່ ~ XNUMX ລ້ານສັ້ນຂອງຕົວເລກຮອບ, ສະນັ້ນໃຫ້ພວກເຮົາພະຍາຍາມແກ້ໄຂມັນ.

ທໍາອິດໃຫ້ເບິ່ງສະຖິຕິທີ່ສ້າງຂຶ້ນ ງາມ:

$ sudo perf stat -B -e task-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,branches,branch-misses,cache-misses ./http_server_multithreaded

 Performance counter stats for './http_server_multithreaded':

     242446,314933      task-clock (msec)         #    4,000 CPUs utilized          
         1 813 074      context-switches          #    0,007 M/sec                  
             4 689      cpu-migrations            #    0,019 K/sec                  
               254      page-faults               #    0,001 K/sec                  
   895 324 830 170      cycles                    #    3,693 GHz                    
   621 378 066 808      instructions              #    0,69  insn per cycle         
   119 926 709 370      branches                  #  494,653 M/sec                  
     3 227 095 669      branch-misses             #    2,69% of all branches        
           808 664      cache-misses                                                

      60,604330670 seconds time elapsed

ໃຊ້ CPU Affinity, ການລວບລວມກັບ -march=native, PGO, ການເພີ່ມຂຶ້ນຂອງຈໍານວນ hits ແຄດ, ເພີ່ມ​ຂຶ້ນ MAX_EVENTS ແລະນໍາໃຊ້ EPOLLET ບໍ່ໄດ້ໃຫ້ປະສິດທິພາບເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ແຕ່ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານເພີ່ມຈໍານວນການເຊື່ອມຕໍ່ພ້ອມໆກັນ?

ສະຖິຕິສໍາລັບ 352 ການເຊື່ອມຕໍ່ພ້ອມໆກັນ:

$ wrk -c352 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 352 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.12ms    3.79ms  68.23ms   87.49%
    Req/Sec    83.78k    12.69k  169.81k    83.59%
  40006142 requests in 1.00m, 5.48GB read
Requests/sec: 665789.26
Transfer/sec:     93.34MB

ຜົນໄດ້ຮັບທີ່ຕ້ອງການແມ່ນໄດ້ຮັບ, ແລະມີເສັ້ນສະແດງທີ່ຫນ້າສົນໃຈສະແດງໃຫ້ເຫັນເຖິງການເພິ່ງພາອາໄສຂອງຈໍານວນຄໍາຮ້ອງຂໍທີ່ດໍາເນີນການໃນ 1 ນາທີກ່ຽວກັບຈໍານວນການເຊື່ອມຕໍ່:

ພວກເຮົາເຫັນວ່າຫຼັງຈາກສອງສາມຮ້ອຍເຊື່ອມຕໍ່, ຈໍານວນຄໍາຮ້ອງຂໍທີ່ປຸງແຕ່ງສໍາລັບທັງສອງເຄື່ອງແມ່ຂ່າຍຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ (ໃນສະບັບຫຼາຍກະທູ້ນີ້ແມ່ນສັງເກດເຫັນຫຼາຍ). ນີ້ກ່ຽວຂ້ອງກັບການປະຕິບັດ Linux TCP/IP stack ບໍ? ຮູ້ສຶກບໍ່ເສຍຄ່າທີ່ຈະຂຽນສົມມຸດຕິຖານຂອງທ່ານກ່ຽວກັບພຶດຕິກໍານີ້ຂອງກາຟແລະການເພີ່ມປະສິດທິພາບສໍາລັບທາງເລືອກຫຼາຍກະທູ້ແລະກະທູ້ດຽວໃນຄໍາເຫັນ.

ວິ​ທີ​ການ ສັງເກດເຫັນ ໃນຄໍາເຫັນ, ການທົດສອບການປະຕິບັດນີ້ບໍ່ໄດ້ສະແດງໃຫ້ເຫັນພຶດຕິກໍາຂອງ I / O reactor ພາຍໃຕ້ການໂຫຼດທີ່ແທ້ຈິງ, ເນື່ອງຈາກວ່າເກືອບສະເຫມີເຄື່ອງແມ່ຂ່າຍພົວພັນກັບຖານຂໍ້ມູນ, ບັນທຶກຜົນໄດ້ຮັບ, ໃຊ້ cryptography ກັບ. TLS ແລະອື່ນໆ, ເປັນຜົນມາຈາກການໂຫຼດໄດ້ກາຍເປັນທີ່ບໍ່ເປັນເອກະພາບ (dynamic). ການທົດສອບຮ່ວມກັບອົງປະກອບຂອງພາກສ່ວນທີສາມຈະຖືກດໍາເນີນຢູ່ໃນບົດຄວາມກ່ຽວກັບ I/O proactor.

ຂໍ້ເສຍຂອງເຄື່ອງປະຕິກອນ I/O

ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າ I/O reactor ບໍ່ແມ່ນບໍ່ມີຂໍ້ບົກຜ່ອງຂອງມັນ, ຄື:

• ການໃຊ້ເຕົາປະຕິກອນ I/O ໃນສະພາບແວດລ້ອມຫຼາຍກະທູ້ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ, ເພາະວ່າ ທ່ານຈະຕ້ອງຈັດການການໄຫຼເຂົ້າດ້ວຍຕົນເອງ.
• ການປະຕິບັດສະແດງໃຫ້ເຫັນວ່າໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການໂຫຼດແມ່ນບໍ່ເປັນເອກະພາບ, ເຊິ່ງສາມາດນໍາໄປສູ່ການຕັດໄມ້ເສັ້ນຫນຶ່ງໃນຂະນະທີ່ຄົນອື່ນກໍາລັງຫຍຸ້ງກັບວຽກ.
• ຖ້າຕົວຈັດການເຫດການຫນຶ່ງບລັອກກະທູ້, ຕົວເລືອກລະບົບຕົວມັນເອງຍັງຈະບລັອກ, ເຊິ່ງສາມາດນໍາໄປສູ່ການຍາກທີ່ຈະຊອກຫາຂໍ້ບົກພ່ອງ.

ແກ້ໄຂບັນຫາເຫຼົ່ານີ້ I/O proactor, ເຊິ່ງມັກຈະມີຕົວກໍານົດເວລາທີ່ແຈກຢາຍການໂຫຼດເທົ່າທຽມກັນກັບສະນຸກເກີຂອງກະທູ້, ແລະຍັງມີ API ທີ່ສະດວກກວ່າ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບມັນຕໍ່ມາ, ໃນບົດຄວາມອື່ນຂອງຂ້ອຍ.

ສະຫລຸບ

ນີ້ແມ່ນບ່ອນທີ່ການເດີນທາງຂອງພວກເຮົາຈາກທິດສະດີໂດຍກົງເຂົ້າໄປໃນທໍ່ profiler ໄດ້ສິ້ນສຸດລົງ.

ທ່ານບໍ່ຄວນຢູ່ກັບເລື່ອງນີ້, ເພາະວ່າມີວິທີການອື່ນໆທີ່ຫນ້າສົນໃຈເທົ່າທຽມກັນໃນການຂຽນໂປຼແກຼມເຄືອຂ່າຍທີ່ມີລະດັບຄວາມສະດວກສະບາຍແລະຄວາມໄວທີ່ແຕກຕ່າງກັນ. ຫນ້າສົນໃຈ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການເຊື່ອມຕໍ່ແມ່ນໃຫ້ຂ້າງລຸ່ມນີ້.

ноновыхвстреч!

ໂຄງການທີ່ຫນ້າສົນໃຈ

• Si
  • ເສລີພາບ
  • ລີເບວ
  • ລີບູ
  • libevhtp
  • ການເປີດເສລີ
  • DPDK
  • ແຜນທີ່ສຸດທິ
  • PF_RING
• rust
  • Mio
  • Tokio
  • smoltcp

ຂ້ອຍຄວນອ່ານຫຍັງອີກ?

• https://linux.die.net/man/7/socket
• https://stackoverflow.com/questions/1050222/what-is-the-difference-between-concurrency-and-parallelism
• http://www.kegel.com/c10k.html
• https://kernel.dk/io_uring.pdf
• https://aturon.github.io/blog/2016/09/07/futures-design/
• https://tokio.rs/blog/2019-10-scheduler/
• https://www.artima.com/articles/io_design_patterns.html
• https://habr.com/en/post/183832/

ແຫຼ່ງຂໍ້ມູນ: www.habr.com