ReadPump и WritePump на соединение

Имена прижились из классического chat example gorilla и теперь встречаются почти в каждом websocket-проекте: readPump — метод клиента, который в вечном цикле читает кадры, writePump — горутина, которая всё пишет. Распределение обязанностей жёсткое и стоит выучить дословно. ReadPump владеет ReadMessage, дедлайном чтения, лимитом размера кадра и pong-обработчиком; на выходе он сигнализирует хабу через unregister и закрывает conn. WritePump владеет всеми WriteMessage — сообщениями, ping и close-кадром; он читает канал send, ставит дедлайн записи перед каждой отправкой и умирает, когда канал закрывается. Никто из них не трогает чужую половину — ни одним вызовом. Хаб же вообще не касается conn: он пишет только в каналы — register, unregister, send клиентов. Такая дисциплина кажется формальностью ровно до первого severed соединения в проде: после неё класс гонок записей просто исчезает, и race detector на нагрузке молчит. В этом уроке мы пройдём оба насоса построчно, а потом посчитаем, во сколько обходится пара горутин на каждый из десяти тысяч клиентов.

Разберём тонкости, которые в этом коде спрятаны. Pong-обработчик вызывает SetReadDeadline — то есть пишет в состояние conn изнутри чтения, и это законно: gorilla вызывает обработчики pong в той же горутине, которая выполняет ReadMessage, — никакого конкурентного доступа нет, продлевать дедлайн чтения может только читатель. Broadcast внутри цикла — передача в небуферизованный канал хаба: чтение блокируется, пока хаб не примет сообщение, и это нормально, потому что цикл run всегда крутится. Заметьте, что readPump никогда не пишет в conn: если хендлеру понадобилось ответить — например, подтверждить команду, — ответ уезжает в send, а не в WriteMessage. Порядок в defer тоже не случайность: unregister стоит первым, потому что именно хаб — владелец close(send); если закрыть conn до вычёркивания, writePump узнает об уходе через ошибку записи, и клиент может мгновение числиться в карте мёртвым. Текущий порядок гарантирует: карта чиста, send закрыт, и только потом соединение умирает физически.

Почему select, а не банальный for range по send? Потому что писателю нужно просыпаться не только для сообщений: ping-тикер должен стрелять по расписанию независимо от трафика, иначе молчаливый клиент с пустым send не получит ни одного ping и дедлайн чтения его убьёт зря. Select развязывает два будильника: пришло сообщение — пишем, тикнул таймер — пингуем, оба сразу — select выберет случайно, и это не страшно, обе операции законны в любом порядке. CloseMessage в ветке ok false — вежливое прощание: сервер инициирует close-рукопожатие с кодом 1000, чтобы клиент получил осознанный сигнал, а не обрыв. SetWriteDeadline перед каждой записью — страховка от особого класса зомби: соединение, у которого сеть наполовину умерла, принимает байты и никуда их не девает; без дедлайна горутина писателя застрянет в такой записи навсегда. Классический пример gorilla здесь ещё и сливает скопившиеся сообщения в один кадр через NextWriter — тот же select, но с батчингом; к нему вернёмся в уроке двадцатом.

Посчитаем всерьёз, сколько websocket горутин несёт реальный сервис. На процесс — одна горутина хаба. На каждое соединение — две: readPump в горутине хендлера и writePump отдельной командой go. Тысяча открытых вкладок — две тысячи и одна горутина; десять тысяч — двадцать тысяч и одна. Звучит угрожающе только до первой арифметики: стартовый стек горутины — порядка двух килобайт, и даже с буфером send на двести пятьдесят шесть сообщений клиент стоит десятки килобайт; двадцать тысяч живых клиентов — сотни мегабайт, и это цена двадцати тысяч одновременных разговоров, а не накладные расходы. Переключение между горутинами дешевле переключения между потоками на порядки, и модель один-клиент-две-горутины остаётся стандартом индустрии именно потому, что Go делает её дешёвой. Бить тревогу нужно не по числу горутин, а по их содержимому: тяжёлая обработка в readPump, большие буферы send, аллокации на каждый кадр — вот где сервис раздувается. Профилирование из продвинутого курса Go — инструмент на этот случай.