Помимо socket-activation есть другой подход: когда процесс передаёт сокет ребёнку, и тот начинает его обрабатывать только тогда, когда всё проинициализировал. После начала обработки отправляется сигнал родителю, и тот завершает свою работу. Интересно то, что ребёнка запускает именно родитель.

Далее я покажу это на примере Linux и systemd, хотя сам механизм должен работать на любом UNIX. И давайте пока вот как договоримся: я покажу высокоуровневую реализацию с готовой библиотекой от cloudflare, а если вы захотите, чтобы я копнул глубже, вы об этом напишете в Telegram канале. Иначе всё-всё в пост не уместишь при всём желании 🙂 

Как это выглядит на практике?   

Нам понадобится библиотека: 

go get -u github.com/cloudflare/tableflip

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

Код на Go: 

package main

import (
	"context"
	"errors"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"

	"github.com/cloudflare/tableflip"
)

const (
	addr            = ":8080"
	shutdownTimeout = 30 * time.Second // время на graceful shutdown
)

func main() {
	upg, err := tableflip.New(tableflip.Options{
		PIDFile: "/run/my-app2.pid",
	})
	if err != nil {
		log.Fatalf("tableflip: %v", err)
	}
	defer upg.Stop()

	log.Printf("PID=%d starting...", os.Getpid())

	mux := http.NewServeMux()
	mux.HandleFunc("/", func(w http.ResponseWriter, _ *http.Request) {
		w.Write([]byte(fmt.Sprintf("Hello from PID %d\n", os.Getpid())))
	})

	srv := &http.Server{Handler: mux}
	ln, err := upg.Listen("tcp", addr) // tableflip сам наследует/передаёт FD
	if err != nil {
		log.Fatalf("listen: %v")
	}

	log.Printf("PID=%d: initializing...", os.Getpid())

	// Имитируем долгую инициализацию
	time.Sleep(5 * time.Second)
	// Здесь мы как бы инициализировались

	// Запускаем сервер
	go func() {
		log.Printf("PID=%d serving on %s", os.Getpid(), addr)
		if err := srv.Serve(ln); err != nil && !errors.Is(err, http.ErrServerClosed) {
			log.Printf("serve: %v", err)
		}
	}()

	// Сообщаем, что готовы принимать трафик, тогда родитель получит Exit() (ниже)
	if err := upg.Ready(); err != nil {
		log.Fatalf("ready: %v", err)
	}
	log.Printf("PID=%d: READY (accepting traffic)", os.Getpid())

	// Обрабатываем сигналы SIGHUP/SIGUSR2 для reload и SIGTERM/SIGINT для shutdown
	waitForSignals(upg)

	// Как только новый процесс скажет Ready(), старый получит Exit()
	waitForExitAndShutdown(upg.Exit(), srv)

	select {} // выше управляем процессом сами
}

func waitForSignals(upg *tableflip.Upgrader) {
	sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, syscall.SIGHUP, syscall.SIGUSR2, syscall.SIGTERM, syscall.SIGINT)
	go func() {
		for s := range sigs {
			switch s {
			// Сигнал родителю при `reload`
			case syscall.SIGHUP, syscall.SIGUSR2:
				log.Printf("PID=%d: upgrade requested", os.Getpid())
				if err := upg.Upgrade(); err != nil {
					log.Printf("upgrade: %v", err)
				}

			case syscall.SIGTERM, syscall.SIGINT:
				log.Printf("PID=%d: stop requested", os.Getpid())
				upg.Stop() // разбудит upg.Exit()
			}
		}
	}()
}

func waitForExitAndShutdown(exit <-chan struct{}, srv *http.Server) {
	go func() {
		<-exit // = upg.Exit()
		log.Printf("PID=%d: received Exit -> graceful shutdown", os.Getpid())
		ctx, cancel := context.WithTimeout(context.Background(), shutdownTimeout)
		defer cancel()

		// Отключаем keep-alive, чтобы клиенты не «зависали» на старом процессе
		srv.SetKeepAlivesEnabled(false)
		if err := srv.Shutdown(ctx); err != nil {
			log.Printf("failed to shutdown server: %v", err)
		}

		// Имитация долгого завершения: можно закрыть БД, дождаться завершения запросов и т.п.
		log.Printf("PID=%d: post-shutdown cleanup...", os.Getpid())
		time.Sleep(5 * time.Second)
		os.Exit(0) // завершаем процесс
	}()
}

И, разумеется, myapp2.service файл для systemd: 

[Unit]
Description=My Go App (tableflip)
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp2
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/my-app2.pid

# Чтобы systemd не убил «ребёнка» во время апгрейда:
KillMode=process
TimeoutStopSec=60

[Install]
WantedBy=multi-user.target

Тестирование

Всё как в прошлый раз: скопируйте бинарник в /usr/bin/myapp2 с правами на исполнение, скопируйте myapp2.service в /etc/systemd/system/. Затем запускаете сервис через systemd start myapp2.

Для теста всё также запускаете команду в соседней вкладке терминала: 

while true; do   printf '%s ' "$(date +'%Y-%m-%dT%H:%M:%S%z')";   curl -s -w " | time=%{time_total}s\n" 127.0.0.1:8080;   sleep 0.2; done

Вы будете видеть примерно такое: 

2025-10-01T04:10:05+0400 Hello from PID 7767
 | time=0.000731s
2025-10-01T04:10:05+0400 Hello from PID 7767
 | time=0.000517s

Затем запускаете systemctl reload myapp2, и спустя 5 секунд, которыми мы выше имитировали "инициализацию" (коннект с базами, чтение файла и так далее) лог станет таким: 

2025-10-01T04:10:05+0400 Hello from PID 7767
 | time=0.000517s
2025-10-01T04:10:06+0400 Hello from PID 7767
 | time=0.000477s
2025-10-01T04:10:06+0400 Hello from PID 22231
 | time=0.000612s
2025-10-01T04:10:06+0400 Hello from PID 22231
 | time=0.000467s

PID сменился, а мы не словили никакого простоя! 

Про PIDFile

PIDFile нужен для того, чтобы systemd знал актуальный ID главного процесса. Иначе при завершении родителя он будет думать, что сервис умер, хотя ребёнок в это время прекрасно существует. Это нормальный подход, но в качестве альтернативы без файла можно передавать в systemd MAINPID из ребёнка, когда он готов обрабатывать запросы.

tableflip пишет новый PID во время вызова Ready(), конечно. Если ребёнок не сможет запуститься, то родитель останется и будет в MAINPID у systemd. 

Минусы подхода

Основной – это, конечно, двойной расход памяти в моменте (старый процесс + новый). И ещё мне не нравится select {}, но я что-то пока не придумал, как сделать лучше.

А в остальном я пока что недостатков не вижу, поэтому буду рад вашему экспертному комментарию в Telegram канале 👋

Существует подход "Socket activation" – это когда вы делегируете прослушивание сокета на systemd. Тогда, даже если ваше приложение не запущено, нужный сокет/порт уже прослушивается, просто не обрабатывается (не принимается), и соединения копятся в очереди. Затем, вместо запуска слушателя, ваше приложение начинает обрабатывать соединения прямо из этого "активированного" сокета.

Как это выглядит на практике?

package main

import (
	"context"
	"errors"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"

	"github.com/coreos/go-systemd/v22/activation"
	"github.com/coreos/go-systemd/v22/daemon"
)

func main() {
	pid := os.Getpid()

	mux := http.NewServeMux()
	mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "ok pid=%d\n", pid)
	})

	srv := &http.Server{Handler: mux}

	// запрашиваем сокет у systemd
	ls, err := activation.Listeners()
	if err != nil {
		log.Fatalf("activation.Listeners: %v", err)
	}
	if len(ls) == 0 {
		log.Fatal("no socket activation listener found")
	}

	// у нас в примере один сокет, поэтому берем первый
	ln := ls[0]

	// запускаем сервер в отдельной горутине
	go func() {
		if err := srv.Serve(ln); err != nil && !errors.Is(err, http.ErrServerClosed) {
			log.Fatalf("serve: %v", err)
		}
	}()

	_, _ = daemon.SdNotify(false, "READY=1")
	log.Printf("started pid=%d", pid)

	sigc := make(chan os.Signal, 1)
	signal.Notify(sigc, syscall.SIGTERM, syscall.SIGINT)
	<-sigc
	log.Print("signal received: graceful shutdown")

	ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
	defer cancel()

	// завершаем сервер
	if err := srv.Shutdown(ctx); err != nil {
		log.Printf("Shutdown error: %v", err)
	}

	// имитация какой-то работы перед завершением
	time.Sleep(2 * time.Second)
}

Не забудь поставить пакет:
go get -u github.com/coreos/go-systemd/v22

И виновник торжества! myapp.socket выглядит так:

[Unit]
Description=MyApp socket

[Socket]
ListenStream=127.0.0.1:8080

[Install]
WantedBy=sockets.target

И myapp.service :

[Unit]
Description=MyApp service
Requires=myapp.socket
After=myapp.socket

[Service]
Type=notify
ExecStart=/usr/local/bin/myapp

[Install]
WantedBy=multi-user.target

Тестирование

Скопируйте бинарник в /usr/local/bin/myapp , сделайте исполняемым, и не забудьте скопировать systemd файлы в /etc/systemd/system/ . Затем запускаете сервис через systemd start myapp.

А затем можете в соседней вкладке терминала запустить такое:

while true; do   printf '%s ' "$(date +'%Y-%m-%dT%H:%M:%S%z')";   curl -s -w " | time=%{time_total}s\n" 127.0.0.1:8080;   sleep 0.2; done

Оно будет раз в 200 мсек отправлять запрос на порт 8080 и писать время ответа.
Теперь если порестартить сервис через systemd restart myapp и посмотреть на вывод:

2025-09-24T04:37:00+0400 ok pid=8715
 | time=0.000296s
2025-09-24T04:37:00+0400 ok pid=8715
 | time=0.000254s
2025-09-24T04:37:01+0400 ok pid=8914
 | time=1.894271s
2025-09-24T04:37:03+0400 ok pid=8914
 | time=0.000416s

То вы увидите, что PID сменился, а значит рестарт случился, но запрос не отвалился, пришлось ли подождать те самые 2 секунды, которые мы заложили под рестарт.

Размер очереди

Обратите обязательно внимание на настройку Backlog в .socket файле: она позволяет вам увеличить очередь, если вдруг запросов в вашем случае очень много, и на все нужно ответить. Полный список опций можете посмотреть тут https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html.

Минусы подхода и когда такой способ не подойдёт

Как вы заметили, в момент рестарта новые соединения хоть и не сбрасываются, но всё равно ждут, когда их начнёт обслуживать новый инстанс. Это терпимо, когда ваш сервис стартует быстро, но если ему нужно сходить в базу, прогреть кеш и что-то другое длительное, то есть другая техника: передача сокета новому процессу тогда, когда новый процесс готов обрабатывать соединения. Своего рода reload.

Как работает time.Now() в Go: путешествие от системных вызовов до наносекунд

Бенчмарки, логи, базы данных, игровые серверы — любое приложение на Go использует время. Это базовая и, казалось бы, простая операция. Но задумывались ли вы, почему time.Now() может работать с разной скоростью на одном и том же компьютере? Откуда Go вообще берёт время? И как разработчики Linux, Windows и macOS решили одну и ту же проблему совершенно разными способами?

Сегодня мы разберёмся с этими вопросами и даже напишем свой собственный time.Now().

Основной способ получить время

Начнём с простого вопроса: кто на вашем компьютере знает время? Очевидно, операционная система. Именно в ней вы настраиваете часовой пояс, синхронизацию и прочее.

Как получить это время в программе? Нужно спросить у операционной системы через системные вызовы — своего рода API операционной системы. В Linux для этого есть функция gettimeofday:

package syscall

import (
    "fmt"
    "syscall"
    "unsafe"
)

type timespec struct {
    Sec  int64
    Msec int64
}

func Now() (int64, int64, error) {
    var ts timespec
    _, _, errno := syscall.Syscall(syscall.SYS_GETTIMEOFDAY, 
        uintptr(unsafe.Pointer(&ts)), 0, 0)
    
    if errno != 0 {
        return 0, 0, fmt.Errorf("error getting time: %s", errno.Error())
    }
    
    return ts.Sec, ts.Msec, nil
}

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

$ go run main.go
Unix Now: 1745090299, Time Now: 1745090299

Работает! Но давайте сравним производительность нашей реализации со стандартной:

BenchmarkSyscall-2     6638930      178.0 ns/op
BenchmarkTimeNow-2    26734690       45.47 ns/op

Разница почти в 4 раза! Но что, если я немного изменю реализацию? После использования некоего vDSO (далее расскажу) мы получаем совсем другие результаты:

BenchmarkVdso-2       26806431       42.00 ns/op
BenchmarkTimeNow-2    26515209       45.92 ns/op

Мы даже обогнали time.Now! Как так получилось? Давайте разбираться.

Цена системных вызовов и vDSO

Проблема в том, что системные вызовы — это как если бы каждый раз, когда вы хотите попить, вам приходилось бы идти в магазин за парой глоточков.

Системные вызовы подразумевают смену контекста исполнения с кода вашей программы на код операционной системы, а затем — восстановление контекста вашей программы. Это необходимо, потому что в коде вашей программы физически нет реализации получения времени. И такое переключение съедает драгоценные наносекунды.

Если проблема в отсутствии кода в нашей программе, то решение простое — подкинуть реализацию при старте программы! Именно так появился vDSO (Virtual Dynamic Shared Object).

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

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

Вот как выглядит работа с vDSO:

package vdso

import (
	"fmt"
	_ "unsafe"

	"golang.org/x/sys/unix"
)

// vdsoClockgettimePtr holds the address found by the runtime.
//
//go:linkname vdsoClockgettimePtr runtime.vdsoClockgettimeSym
var vdsoClockgettimePtr uintptr

// vdsoCallClockgettimeAsm is the Go declaration for our internal assembly function.
// Implementation is in vdso_asm_arm64.s
func vdsoCallClockgettimeAsm(vdsoFuncPtr uintptr, clockid uintptr, ts *unix.Timespec) int64

// vdsoClockGettimeAsmWrapper calls the assembly function and interprets the result.
// Internal helper function.
func vdsoClockGettimeAsmWrapper(clockid int) (sec int64, nsec int64, err error) {
	var ts unix.Timespec
	ret := vdsoCallClockgettimeAsm(vdsoClockgettimePtr, uintptr(clockid), &ts)

	if ret != 0 { // ret should be -1 on error
		return 0, 0, fmt.Errorf("vDSO assembly call failed (ret=%d)", ret)
	}
	return ts.Sec, ts.Nsec, nil
}

// Now returns the current time using CLOCK_REALTIME.
// It attempts to use the vDSO via assembly for performance,
// falling back to a standard syscall if vDSO is unavailable or fails.
func Now() (sec int64, nsec int64, err error) {
	// Try vDSO first if the pointer is available
	if vdsoClockgettimePtr != 0 {
		sec, nsec, err = vdsoClockGettimeAsmWrapper(unix.CLOCK_REALTIME)
		// If vDSO call succeeded, return the result
		if err == nil {
			return sec, nsec, nil
		}
	}

	// Fallback to standard syscall if vDSO pointer is null or vDSO call failed
	var ts unix.Timespec
	syscallErr := unix.ClockGettime(unix.CLOCK_REALTIME, &ts)
	if syscallErr != nil {
		// If both vDSO (if attempted) and syscall failed, return the syscall error
		return 0, 0, fmt.Errorf("vdso: syscall fallback failed: %w", syscallErr)
	}

	// Return result from successful syscall fallback
	return ts.Sec, ts.Nsec, nil
}

Давайте по порядку разберём самое непонятное:

1. var vdsoClockgettimePtr uintptr – адрес функции clockgettime в пространстве процесса
2. //go:linkname vdsoClockgettimePtr runtime.vdsoClockgettimeSym – ничто иное, как хак в образовательных целях, чтобы не маппить адреса clockgettime на каждой архитектуре самостоятельно. В Go уже есть все эти адреса, и через go:linkname я всего лишь прошу компилятор сделать так, чтобы обращение к vdsoClockgettimePtr было на самом деле обращением к внутренней runtime.vdsoClockgettimeSym
3. func vdsoCallClockgettimeAsm(vdsoFuncPtr uintptr, clockid uintptr, ts *unix.Timespec) int64 – а вот тут интересно! Заголовок функции есть, а вот реализация в соседнем файле vdso_asm_arm64.s

TEXT ·vdsoCallClockgettimeAsm(SB), NOSPLIT, $0-32
    MOVD vdsoFuncPtr+0(FP), R10    // Адрес функции vDSO
    MOVD clockid+8(FP), R0         // Первый аргумент
    MOVD ts+16(FP), R1             // Второй аргумент
    CALL (R10)                     // Вызываем функцию
    MOVD R0, ret+24(FP)           // Возвращаем результат
    RET

А почему здесь потребовался ассемблер?

Основная причина для меня – я не знаю как на Go вызвать функцию по указателю vdsoClockgettimePtr. Поэтому я самостоятельно кладу данные в регистры и вызываю функцию через CALL.

Как сделано в macOS: commpage

На macOS системный вызов тоже работает медленно:

BenchmarkSyscall-10     5107172      231.6 ns/op
BenchmarkTimeNow-10    29132193       41.96 ns/op

Разница более чем в 5 раз! Но vDSO там нет (поверьте). Как же тогда?

macOS использует другой подход: вместо функции она даёт доступ к особому региону памяти, в котором периодически обновляет время. Это как если бы вода удивительным образом появлялась прямо на вашем столе.

Такая общая страница называется commpage, и Go к ней даже не обращается напрямую! Вместо этого Go использует системную библиотеку:

func Now() (int64, int64, error) {
    var ts unix.Timespec
    // Используем высокоуровневую обёртку вместо сырого syscall
    err := unix.ClockGettime(unix.CLOCK_REALTIME, &ts)
    if err != nil {
        return 0, 0, err
    }
    return ts.Sec, ts.Nsec, nil
}

А unix.ClockGettime выглядит как:

func ClockGettime(clockid int32, time *Timespec) (err error) {
	_, _, e1 := syscall_syscall(libc_clock_gettime_trampoline_addr, uintptr(clockid), uintptr(unsafe.Pointer(time)), 0)
	if e1 != 0 {
		err = errnoErr(e1)
	}
	return
}

И результаты говорят сами за себя:

BenchmarkSyscall-10    21755354       48.90 ns/op
BenchmarkTimeNow-10    28316968       42.57 ns/op

Системная библиотека знает про commpage и самостоятельно решает, когда использовать её, а когда — системный вызов.

Как сделано в Windows: User Shared Data

Windows пошла по пути, похожему на macOS. Традиционно посмотрим на результаты с использованием Windows API:

BenchmarkWinApi-4      29055982       41.50 ns/op
BenchmarkTimeNow-4     352143674       3.412 ns/op

Вау! time.Now() работает в 12 раз быстрее! Как Windows добилась такой скорости?

Ответ — в прямом чтении памяти. В памяти процесса есть особая страница User Shared Data, которая находится по фиксированному адресу 0x7FFE0000:

const (
    systemTimeAddr uintptr = 0x7ffe0014
    epochOffset int64 = 116444736000000000  // Разница между эпохами Windows и Unix
)

func Now() (sec int64, nsec int64, err error) {
    // Читаем время напрямую из памяти
    ticks := *(*int64)(unsafe.Pointer(systemTimeAddr))
    
    // Конвертируем из Windows-эпохи в Unix-эпоху
    unixTicks := ticks - epochOffset
    totalNsec := unixTicks * 100
    
    sec = totalNsec / int64(time.Second)
    nsec = totalNsec % int64(time.Second)
    
    return sec, nsec, nil
}

И если использовать User Shared Data, то результат вас удивит:

BenchmarkWinShared-4   1000000000      0.3412 ns/op
BenchmarkTimeNow-4      344631338      3.439 ns/op

Наша реализация работает в 10 раз быстрее! Это возможно, потому что мы делаем минимум работы — просто читаем значение из памяти. Go же выполняет дополнительные проверки и преобразования.

Интересно, что помимо времени в User Shared Data есть множество другой информации: количество процессоров, возможности процесса, номер сборки ОС и многое другое.

Монотонное и настенное время

Но есть ещё одна загадка. Linux предоставляет целую функцию, но Windows и macOS просто обновляют время в памяти. Но они же не могут делать это каждую наносекунду! Откуда тогда берётся наносекундная точность в бенчмарках?

И что произойдёт, если во время бенчмарка изменить системное время на час назад? Покажет ли бенчмарк отрицательное время?

Ответ в том, что существует два типа времени:

1. Настенное время (wall clock time) — то, что вы видите на часах. Его можно переводить вперёд или назад, оно может корректироваться от сервера времени.
2. Монотонное время (monotonic time) — непреклонный аппаратный счётчик с момента включения компьютера. Оно никогда не идёт вспять и не ускоряется, и в этом его прелесть.

Когда в Go вы вычитаете одно время из другогоtime.Sub(...), Go проверяет наличие монотонного времени в структуре и использует именно его:

// В структуре time.Time есть поле для монотонного времени
type Time struct {
    wall uint64
    ext  int64    // Может содержать монотонное время
    loc  *Location
}

func (t Time) Sub(u Time) Duration {
    //Если есть монотонное время, то...
	if t.wall&u.wall&hasMonotonic != 0 {
        //вычитаем именно его!
		return subMono(t.ext, u.ext)
	}
	d := Duration(t.sec()-u.sec())*Second + Duration(t.nsec()-u.nsec())
	// Check for overflow or underflow.
	switch {
	case u.Add(d).Equal(t):
		return d // d is correct
	case t.Before(u):
		return minDuration // t - u is negative out of range
	default:
		return maxDuration // t - u is positive out of range
	}
}

func subMono(t, u int64) Duration {
	d := Duration(t - u)
	if d < 0 && t > u {
		return maxDuration // t - u is positive out of range
	}
	if d > 0 && t < u {
		return minDuration // t - u is negative out of range
	}
	return d
}

Благодаря этому бенчмарки всегда показывают реальное прошедшее время, независимо от изменений системных часов.

Итоги

Подведём итоги нашего путешествия:

1. Наивный подход с системными вызовами работает, но медленно из-за переключения контекста.
2. Каждая ОС решает проблему по-своему:
   • Linux использует vDSO — подкидывает функции в адресное пространство процесса
   • macOS использует commpage — обновляемую ядром страницу памяти, доступ к которой организует системная библиотека
   • Windows использует User Shared Data — страницу по фиксированному адресу, которую мы читаем напрямую
3. Два типа времени решают разные задачи: настенное для отображения, монотонное для измерений.

Вот так простая операция time.Now() оказывается результатом десятилетий оптимизаций и архитектурных решений. В следующий раз, когда будете измерять производительность своего кода, вспомните, какой путь проходит каждый вызов получения времени — от вашей программы через хитрые оптимизации операционной системы до аппаратных счётчиков процессора.

Не забывайте подписываться и на Telegram канал, там я публикую в том числе короткие статьи о разных внутренностях Go:

Славный АйТи – анонсы, технологии, GoLang

Привет! Я GoLang разработчик, тимлид и автор канала про айтишечку https://www.youtube.com/@VyacheArt Буду радовать вас роликами про хайлоад, рекламу и про всё то, что я знаю, а вам интересно послушать. @VyacheslavG

Telegram

Источники

Ниже перечислил полезные ссылки, если захотите покопать сами. Безусловно большая часть материала была основана на исходном коде в пакете runtime, но большую благодарность заслуживают ещё множество авторов, которые тоже копали время до меня.

1. https://pkg.go.dev/time
2. https://man7.org/linux/man-pages/man2/settimeofday.2.html
3. https://man7.org/linux/man-pages/man7/vdso.7.html
4. go/src/runtime/time_linux_amd64.s
5. https://docs.darlinghq.org/internals/macos-specifics/commpage.html
6. https://deviltux.thedev.id/notes/pure-reverse-engineering/
7. Описание структуры KUSER_SHARED_DATA в доке Microsoft
8. Подробная история, назначение и множество информации о KUSER_SHARED_DATA (не Microsoft)
9. Обращение к KSHARED_USER_DATA d ReactOS
10. Обращение к libc на macOS при использовании time.Now
11. https://www.willem.dev/articles/time-now-monotonic-clock/
12. https://tpaschalis.me/golang-time-now/

Мы разработчики программного обеспечения, и мы можем делать классные вещи. Но в каждой профессии есть и рутина, на которую мы регулярно тратим время. Например, перевести строку в HEX/Base64/SHA/MD5, конвертировать WebP изображение, сгенерировать UUID, в конце концов настроить Cron.

Меня не устроили существующие решения, и я создал Web Artisan Pro – решение, которое совмещает в одном месте весь ворох небольших утилит: от форматировщиков до генераторов с кучей опций для настройки, с кроссплатформенностью и доступом из консоли.

Я регулярно пользуюсь Web Artisan Pro сам (в первую очередь и создавал для себя), и лично слежу за тем, чтобы всё было удобно. Попробуйте и вы!

Переходите в телеграм бота Web Artisan Pro https://t.me/WebArtisanProBot и получайте пожизненную лицензию. А взамен я буду счастлив услышать ваш отзыв, чтобы сделать проект лучше!

🔹 Получить бесплатный ключ через бота
🔹 Официальный сайт Web Artisan Pro

На данный момент уже вышло несколько обновлений! Читайте список изменений!

type Storage interface {
    Save(data []byte) error
}

type FileStorage struct {
    path string
}

func (fs *FileStorage) Save(data []byte) error {
    return os.WriteFile(fs.path, data, 0644)
}

func main() {
    // Работает
    var s1 Storage = &FileStorage{path: "data.txt"}
    
    // Не компилируется
    // "Cannot use FileStorage{path: "data. txt"} (type FileStorage) as the type Storage"
    // "Type does not implement Storage as the Save method has a pointer receiver"
    var s2 Storage = FileStorage{path: "data.txt"}
}

Почему так? Ведь метод Save у нас есть. В чём подвох?

Разбор

Дело в том, что метод Save объявлен на указателе (*FileStorage), а не на значении. И тут начинается самое интересное.

Когда вы объявляете метод на указателе, Go позволяет вам вызывать его и для указателя, и для значения:

storage := FileStorage{path: "data.txt"}
storage.Save([]byte("hello"))  // Работает

ptr := &storage
ptr.Save([]byte("world"))      // Тоже работает

В первом случае Go неявно берет адрес значения storage, чтобы вызвать метод. Но с интерфейсами такое поведение не работает. Если метод объявлен на указателе, то только указатель может реализовывать интерфейс. 

Это сделано намеренно. Представьте, что у вас временное значение:

func getStorage() FileStorage {
    return FileStorage{path: "temp.txt"}
}

var storage Storage = getStorage() // Не скомпилируется

Если бы Go автоматически брал адрес значения при присваивании интерфейсу, то вы бы получили указатель на временное значение, которое исчезнет после возврата из функции.

А вот обратная ситуация работает без проблем:

type Reader interface {
    Read() string
}

type MemoryReader struct {
    data string
}

// Метод на значении
func (mr MemoryReader) Read() string {
    return mr.data
}

func main() {
    // Оба варианта работают
    var r1 Reader = MemoryReader{data: "hello"}
    var r2 Reader = &MemoryReader{data: "world"}
}

Когда метод объявлен на значении, его можно вызвать и для указателя – Go просто разыменует указатель автоматически.

Так какой же receiver выбрать?

Используйте pointer receiver, если:

• Метод должен изменять состояние структуры
• Структура большая и копировать её накладно
• У других методов этого типа уже есть pointer receiver (для консистентности!)
• Когда тип содержит sync.Mutex или другие поля, которые нельзя копировать

В остальных случаях используйте value receiver.

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

Строго говоря это подборка именно для новичков в Go, и я ожидаю, что программировать на другом языке вы уже умеете 🙂. А если нет, то смело подписывайтесь, и я научу.

Идеи и описание

gRPC

Go

A high-performance, open source universal RPC framework

gRPC

Любое серверное ПО скорее всего будет как-то общаться с другими сервисами. И есть протокол, который позволяет вам делать это эффективно, быстро и независимо от языка: gRPC.

gRPC (gRPC Remote Procedure Call) - это высокопроизводительный фреймворк с открытым исходным кодом, разработанный Google для создания эффективных и масштабируемых API. Он использует протокол HTTP/2 для передачи данных и позволяет определять интерфейс сервиса с помощью языка описания интерфейса (IDL) под названием Protocol Buffers, обеспечивая типизированную, эффективную и независимую от языка программирования коммуникацию между клиентом и сервером.

Ключевые плюсы

1. Компактность: gRPC обменивается данным в бинарном формате
2. Расширяемость: в структуры Protocol Buffers очень легко добавлять новые поля без потери совместимости с прошлыми версиями
3. Обмен данными в реальном времени со streaming функциями

Идеи

1. Чат в реальном времени
2. Мультиплеерный Flappy Bird
3. Клон сайта "миллион чекбоксов"
4. Удалённое управление и мониторинг своего компьютера

WEB

Огромная область, в которой го очень популярен – это веб.

Для работы с базой данных вам пригодится библиотека GORM: https://github.com/go-gorm/gorm.

Захотите обновлять информацию в реальном времени, тогда выбирайте WebSocket и библиотеку gorilla/websocket: https://github.com/gorilla/websocket.

Идеи

1. Гостевая книга а-ля "Твиттер" или "X" с обновлением записей в реальном времени
2. Библиотека книг и сериалов
3. Генератор форм для опросов
4. Библиотека отзывов
5. Личная визитница

Данные

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

Для хранения в оперативной памяти можно начать с классических хеш-таблиц, и сосредоточиться на дизайне API и способах эффективного хранения разных типов.

Для постоянного хранения можно пойти в сторону LSM деревьев.

LSM (Log-Structured Merge) деревья - это структура данных, оптимизированная для быстрой записи и эффективного хранения большого объема данных на диске. Основная идея заключается в том, что новые данные добавляются в память в виде отсортированных блоков (называемых "сегментами" или "чанками"), а затем периодически сливаются с существующими данными на диске, образуя новые, более крупные отсортированные блоки.

Идея

Key-value хранилище или in-memory кеш.

PKCS #11 – это уже стандарт программной имплементации интерфейса доступа к смарт-картам, токенам и другим криптографическим устройствам.

По итогу получится такая схема, когда публичный и приватный ключ будет храниться прямо на YubiKey, никогда его не покинет, а значит невозможно будет аутентифицироваться без физически подключённого YubiKey. Двигаемся дальше.

YubiKey предоставляет интерфейс PKCS #11, а SSH умеет подгружать специфическую динамическую библиотеку, которая и будет отвечать за взаимодействие по интерфейсу PKCS #11 c YubiKey. И нам останется лишь сгенерировать ключи, добавить их на сервер, и наслаждаться секьюрным решением!

Весь процесс проделывал с:

• YubiKey 5C NFC;
• macOS 14.5 Sonoma.

Подготовка

Нам понадобится взаимодействовать с YubiKey для дальнейшей генерации ключей. Для этого понадобится установить две утилиты: Yubico PIV Tool и Yubikey Manager.

macOS

На macOS для этого можно использовать brew:

brew install yubico-piv-tool yubico-yubikey-manager

И важно скопировать динамическую библиотеку, которая понадобится нашему SSH позже:

sudo cp /opt/homebrew/Cellar/yubico-piv-tool/2.3.1/lib/libykcs11.2.3.1.dylib /usr/local/lib/libykcs11.dylib

Обратите внимание, что в моём случае версия yubico-piv-tool была 2.3.1. Замените номер версии на тот, который у вас.

Первоначальная настройка YubiKey

В этой части мы установим PIN и PUK коды, и сгенерируем "management key" для безопасного взаимодействия с YubiKey.

Если всё это вы уже настроили, то можете перейти к следующему шагу.

1. Мы будем работать с командой ykman. Она поставляется вместе с Yubikey Manager, поэтому для удобства можем прописать alias:

alias ykman="/Applications/YubiKey\ Manager.app/Contents/MacOS/ykman"

2. Далее установим PIN и PUK код
   1. PIN код – тот, который вы будете вводить при использовании YubiKey
   2. PUK код – тот, который нужно будет ввести, если вы забудете PIN и израсходует попытки ввода (да, они ограничены)

ykman piv access change-pin
ykman piv access change-puk

3. Последнее что остаётся – сгенерировать management key, который мы будем использовать далее при заполнении PIV слотов. Строго говоря его генерация необязательна (вроде), но без неё у меня далее ничего не работало. Поэтому запускаем команду

ykman piv access change-management-key --generate --protect

Генерация ключей

Приватный ключ

Для подписи дальнейших шагов нужно сгенерировать ключ следующей командой:

yubico-piv-tool --key -s 9a -AECCP384 -a generate --pin-policy=once --touch-policy=always -o public.pem

Эта команда сгенерирует приватный ключ прямо на YubiKey, и сохранит на вашем компьютере публичный ключ в файл public.pem.

Вы также можете поправить некоторые опции:

• --pin-policy – политика ввода PIN кода. Возможные значения:
  • never – никогда не вводить пин-код, достаточно подключённого YubiKey;
  • always – вводить пароль при каждом использовании;
  • once – вводить пароль единожды для каждой сессии. Сессия – период между подключением и отключением YubiKey.
• --touch-policy – политика требования касания сенсорной кнопки YubiKey. Возможные значения:
  • never – никогда не требоваться касания:
  • always – всегда требовать касание;
  • cached – не требовать касание в течение 15 секунд после последнего (удобно, когда нужно залогиниться в несколько мест сразу).

Подробнее про опции можете почитать в официальной документации.

PIV сертификат

Стандарт PIV требует использование сертификата. Поскольку выше мы предпочли сгенерировать приватный ключ прямо на YubiKey, то нам достаточно запустить одну команду:

yubico-piv-tool --key -a verify-pin -a selfsign-certificate -s 9a --subject "/CN=SSH key/" --valid-days=3650 -i public.pem -o cert.pem

И сертификат окажется в слоте 9a на YubiKey.

Публичный SSH ключ

И остаётся последнее: получить публичный SSH ключ, чтобы затем добавить его на сервере:

ssh-keygen -D /usr/local/lib/libykcs11.dylib -e

Команда выведет публичный ключ, который нужно добавить в ~/.ssh/authorized_keys на вашем сервере.

И после этого можно пытаться залогиниться:

ssh -o "PKCS11Provider /usr/local/lib/libykcs11.dylib" user@remote

Здесь вы можете столкнуться с проблемой, что SSH не сможет "спросить" у вас пин-код. Если такое случится, то вам нужно установить скрипт этого самого окна, чтобы SSH в него "перенаправил" запрос пин-кода. Самое простое: установить brew install michaelroosz/ssh/libsk-libfido2-install (и пусть вас не смущает FIDO2, в комплекте автор оставил нужный нам скрипт), и затем прописать переменные окружения в вашем _~/.zshrc или ~/.bash_profile:

export SSH_ASKPASS=/opt/homebrew/bin/ssh-askpass
export DISPLAY=":0"

Желательно это делать в самом верху файла, если у вас установлен автоматический ssh-agent. Тогда он будет использовать эту конфигурацию.

Пара советов

Рекомендую прописать PKCS11Provider в вашем ~/.ssh/config, чтобы не нужно было писать эту опцию каждый раз руками:

Host *
    PKCS11Provider /usr/local/lib/libykcs11.dylib

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

Host bitbucket.org
    ControlMaster auto
    ControlPath ~/.ssh/S.%r@%h:%p
    ControlPersist 10m

Ссылки

Обязательно смотрите сам ролик про мою попытку безопасно работать с SSH: Как использовать SSH ПРАВИЛЬНО | YubiKey, FIDO2, PIV и правила использования SSH ключей.

Статьи, видео и инструкции не появилось бы без следующих материалов:

1. PIV Walk-Through в официальной документации
2. Вновь официальная документация по ykman
3. Великолепная инструкция от человека с ником m3nu, которая легла в основу этой статьи

Весь процесс проделывал с:

• YubiKey 5C NFC;
• macOS 14.5 Sonoma.

Однако во многом инструкция подойдёт и для других систем, специфичные шаги я далее отмечу.

Подготовка

Для начала нужно убедиться, что установленный OpenSSH версии не ниже 8.3:

ssh -V

Если ниже, то обновитесь доступным способом, например, через brew.

macOS

Однако даже если версия SSH у вас корректная, скорее всего при выполнении дальнейших шагов вы столкнётесь с ошибкой:

Key enrollment failed: unknown or unsupported key type

Связано это с тем, что встроенный OpenSSH в macOS по умолчанию не поддерживает sk ключи. Но это легко исправить!

Есть GitHub Issue, в котором прекрасный человек под ником MichaelRoosz собрал все необходимые библиотеки в виде brew пакета, и на этапе подготовке давайте сразу установим этот пакет:

brew install michaelroosz/ssh/libsk-libfido2-install

После установки остаётся только прописать переменную окружения SSH_SK_PROVIDER и SSH_ASKPASS в вашем _~/.zshrc или ~/.bash_profile:

export SSH_SK_PROVIDER=/usr/local/lib/libsk-libfido2.dylib
export SSH_ASKPASS=/opt/homebrew/bin/ssh-askpass

И мы готовы к самому главному: генерации ключей.

Генерация

Поскольку перед нами стоит задача сгенерировать FIDO2 ключ, дальнейший путь разделяется на две дороги: нужно решить генерировать резидентский или нерезидентский ключ. Чем они отличаются?

Нерезидентский FIDO2 ключ

Когда конечная сторона (приложение или веб-сайт) хочет аутентифицировать вас, оно отправляет обязательный Credential ID. Это некая зашифрованная информация, которую расшифровать может ли ваш аппаратный ключ.

Сам процесс происходит за счёт использования уникального мастер-ключа. Обратите внимание, что это именно мастер-ключ: он один для всего аппаратного ключа, а вторую часть "формулы" – Credential ID, обязано предоставить приложение. Но при этом ни один из ваших аккаунтов не хранится в YubiKey, поэтому место нерезидентские ключи не расходуют, и их количество неограниченно.

Резидентский FIDO2 ключ

Резидентские или обнаруживаемые ключи, напротив, занимают слот на вашем аппаратном ключе. Их количество может разниться в зависимости от модели: на некоторых 8 слотов, на YubiKey 5 от 25 до 32, а на некоторых слотов нет совсем, а значит резидентский ключ сгенерировать невозможно.

В данном случае приложению не нужно предоставлять Credential ID: вся необходимая информация формируется на аппаратном ключе в момент добавления аккаунта. Если аккаунтов несколько, то браузер предложит выбрать конкретный. И далее уже сам ключ "расскажет" конечной стороне Credential ID и необходимую информацию для аутентификации.

Также сама по себе работа с резидентскими FIDO2 ключами отличаются из-за разных версий стандарта CTAP. На данный момент существуют версии 2.0, 2.1PRE и 2.1. И лишь 2.1PRE и 2.1 дают возможность вам удалить (освободить слот) резидентский ключ с устройства без сброса всего хранилища. Было бы неприятно добавить 25 ключей, и ради удаления одного сбрасывать все, м?

Так что выбрать, что безопаснее?

Обе опции являются безопасными. Да, в случае резидентского ключа вообще все чувствительные данные хранятся на аппаратном ключе, а у нерезидентского Credential ID есть у приложения. Однако нельзя сказать, что последнее плохо: Credential ID шифруется с AES128, а это довольно надёжный стандарт.

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

Команды

Для генерации не-резидентского ключа запустите:

ssh-keygen -t ed25519-sk

А для генерации резидентского:

ssh-keygen -t ed25519-sk -O resident -O application=ssh:my-hostname -O verify-required

Вместо ssh:my-hostname можете ввести любой текст, и далее он будет отображаться в Yubico Authenticator (или другом менеджере вашего аппаратного ключа в списке FIDO2):

И, кстати, да, генерация происходит привычным ssh-keygen. Если вы не пропустили шаг с подготовкой для macOS, то сейчас утилита должна попросить ввести пин-код и коснуться ключа. А по итогу появится id_ed25519_sk SSH ключ.

Публичную часть необходимо выгрузить на сервер:

ssh-copy-id -i ~/.ssh/id_ed25519_sk user@remote

После чего вы можете убедиться, что всё работает:

ssh -i ~/.ssh/id_ed25519_sk -o 'IdentitiesOnly yes' user@remote

Победа 🙂

Ссылки

Обязательно смотрите сам ролик про мою попытку безопасно работать с SSH: Как использовать SSH ПРАВИЛЬНО | YubiKey, FIDO2, PIV и правила использования SSH ключей.

И огромное количество информации я узнал благодаря статьям других авторов:

1. Discoverable vs non-discoverable credentials в документации YubiKey
2. How passkeys work в документации YubiKey
3. ssh authentication via Yubikeys
4. How Hype Will Turn Your Security Key Into Junk про разницу резидентских и не-резидентских ключей
5. Тот самый Github Issue с решением для macOS и кучей полезной информации

А достаточно ли использовать пароль на SSH ключе? Как часто менять свой SSH ключ? И как правильно передавать (или вообще не передавать?!) свой SSH ключ?

Обо всём этом, а самое главное о комбинации SSH и YubiKey расскажу в этом видео.

Инструкции

Как настроить SSH с FIDO2 и YubiKey на macOS

По мотивам https://youtu.be/JeGVH0v68_I. Как использовать аппаратный ключ для аутентификации по SSH? Для этого существует стандарт FIDO2, который позволяет использовать внешнее устройство. В этой статье как расскажу о том, как настроить вход с использованием аппаратного ключа YubiKey на macOS. Весь процесс проделывал с: * YubiKey 5C NFC; * macOS

Славный АйТиВячеслав Горюнов

Как настроить SSH с PIV и YubiKey на macOS

это стандарт двухфакторной аутентификации с использованием смарт-карт. И есть более специфический стандарт, который чаще всего используется в этом направлении: PKCS #11. PKCS #11 – это уже стандарт программной имплементации интерфейса доступа к смарт-картам, токенам и другим криптографическим устройствам. По итогу получится такая схема, когда публичный и приватный ключ будет храниться

Славный АйТиВячеслав Горюнов

Ссылки

Огромное количество информации я узнал благодаря статьям других авторов:

1. Discoverable vs non-discoverable credentials в документации YubiKey
2. How passkeys work в документации YubiKey
3. ssh authentication via Yubikeys
4. How Hype Will Turn Your Security Key Into Junk про разницу резидентских и не-резидентских ключей
5. Тот самый Github Issue с решением для macOS и кучей полезной информации