Что такое Completion Ports (IOCP)?

А, слушай, про IOCP рассказывать? Ну это же, ёпта, святая святых для любого, кто на Windows сервер под тысячу коннектов пилит. Представь себе бардак: у тебя куча сокетов, данные туда-сюда летят, а твои потоки тупо спят, ожидая, когда что-то придёт. Это же пиздец, масштабируемость — ноль ебать. Так вот, I/O Completion Ports — это как раз та хитрая жопа, которая позволяет не ебаться с этим бардаком.

Как оно, блядь, работает, если по-простому: Вместо того чтобы поток намертво виснуть заставлять на операции (типа recv), ты говоришь системе: «Слушай, а сделай-ка мне это дело асинхронно, а как закончишь — дай знать». Ты инициируешь операцию (скажем, WSARecv), передаёшь ей специальную структуру OVERLAPPED и свой буфер, а потом — похуй, свободен. Система сама, своим чёрным ядром, ждёт, когда данные придут. А когда пришли — она плюхает уведомление о завершении в специальную очередь, которая и называется портом завершения. А у тебя есть пул рабочих потоков, которые тупо сидят и ждут на этой очереди вызовом GetQueuedCompletionStatus. Как только там что-то появляется — система будит ровно столько потоков, сколько нужно для обработки. Никаких лишних пробуждений, контекстных переключений — овердохуища. Красота!

Вот смотри, как примерно это в коде выглядит, чувак:

#include <winsock2.h>
#include <windows.h>
#include <memory>

// Это наша структура, где мы всё своё барахло для операции складываем.
// Главное — первым полем должен быть WSAOVERLAPPED, система на это завязана.
struct PerIoData {
    WSAOVERLAPPED overlapped; // Без этого нихуя не заработает, это как пропуск.
    WSABUF wsaBuf;            // А тут сам буфер и его размер.
    char buffer[1024];
    SOCKET socket;            // Какой сокет сработал — чтобы знать.
    // ... тут ещё можно твой контекст пихать, указатели, счётчики — что угодно.
};

// Создаём сам порт завершения. Это наша главная очередь.
HANDLE completionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);

// Подключаем к нему сокет. Теперь все операции с этого сокета будут в эту очередь падать.
CreateIoCompletionPort((HANDLE)clientSocket, completionPort, (ULONG_PTR)contextPtr, 0);

// Готовим данные для асинхронного чтения.
auto perIoData = std::make_unique<PerIoData>();
perIoData->wsaBuf.buf = perIoData->buffer;
perIoData->wsaBuf.len = sizeof(perIoData->buffer);
perIoData->socket = clientSocket;

// Запускаем чтение! Обрати внимание — последний аргумент &(perIoData->overlapped).
// Мы говорим системе: «Вот тебе структура, работай. Как закончишь — отзовись через неё».
DWORD flags = 0;
WSARecv(clientSocket, &(perIoData->wsaBuf), 1, NULL, &flags, &(perIoData->overlapped), NULL);

// А это уже код рабочего потока, который висит на очереди и ждёт.
DWORD bytesTransferred;
ULONG_PTR completionKey;
LPOVERLAPPED overlapped;
while (GetQueuedCompletionStatus(completionPort, &bytesTransferred, &completionKey, &overlapped, INFINITE)) {
    // Система вернула нам тот самый overlapped, который мы передавали.
    // Кастуем его обратно к нашей структуре — и вуаля, все наши данные на месте.
    auto data = reinterpret_cast<PerIoData*>(overlapped);
    // data->buffer теперь содержит прочитанные данные, bytesTransferred — сколько их.
    // Делай с ними что хочешь.
    // ...
}

И в чём, собственно, кайф для C++ сервера:

• Масштабируемость пиздец: Ты можешь держать десятки тысяч соединений, а потоков у тебя будет столько, сколько ядер у процессора. Никакой ебли с тысячей потоков, которые только мешают друг другу.
• Контекстные переключения — на минимум: Система не будит лишние потоки, только те, кому есть работа. Это ж экономия какая, ядрёна вошь!
• Гибкость конская: Ты можешь привязать к операции любой свой контекст (этот completionKey), чтобы не ебаться с поиском, к какому сокету или пользователю эти данные относятся. Удобно, бля.

На Линуксах, кстати, примерно такую же роль выполняют epoll и новый монстр io_uring. Но в винде — это наш родной, блядовитый, но чертовски эффективный механизм. Если хочешь писать быстрые сетевые сервисы под Windows — без него нихуя.