ssh3라는 이름이 정말 마음에 안 들었음, 레포 최상단에 “SSH3는 이름이 바뀔 예정임. 아직은 SSH Connection Protocol(RFC4254)이 HTTP/3 Extended connect 위에서 동작하는 형태이지만, 필요한 변경 사항이 많고 기존 SSH와 너무 달라서 쉽게 통합될 수 없는 수준임. 명세 초안은 이미 ‘Remote Terminals over HTTP/3’로 바꿨고, 더 나은 영구적 이름을 고민할 시간이 필요함”이라고 써 놓아서 좋았음
이런 이름은 마치 누가 “Windows 12”나 “Linux 7”이란 레포 만든 것 같이 어울리지 않는 느낌임
SSH3 대신 Secure Hypertext Interactive TTY 같은 이름 제안임
SSH/3는 어떨지 생각해봤음 (SSH + HTTP/3 느낌)
이 Thread는 정말 본격적인 ‘bike-shedding’ 논쟁의 명작임
SSH2/3 정도면 어떨까 생각해봤음, 대부분 SSH2인데 HTTP/3 위에 올라가는 구조임
SSH가 느린데, 내 경험상 가장 큰 병목은 세션 셋업에 있다는 의견임. PAM 같은 것 때문이든, OpenBSD의 정책이든, SSH 연결을 재사용하던 새로 만들던 매번 세션 셋업 단계가 심각하게 느림. 장시간 세션에선야 괜찮지만, 간단하게 커맨드 하나 실행하려고 해도 매번 오버헤드가 있기에 Ansible 성능도 만족스럽지 않았고, 그래서 세션 오버헤드 없는 리모트 커맨드 실행 미니 ansible을 직접 만들게 되었음
‘이게 진짜 전통적인 SSH보다 빠르다고?’ 의심이 들었는데, README 보니 연결 설정 단계만 빠르고, 연결 이후 실제 속도는 동일하다고 해서 납득했음. 이 정도만 해도 타당한 개선임
실제로는 그런 의미에서 더 빠르진 않음. 단일 SSH 연결에서 여러 포트를 트래픽 포워딩할 때 헤드오브라인 블로킹이 생기는데, QUIC/HTTP3 프로토콜은 이런 문제를 해결할 수 있음
내기해도 좋지만, 이 프로토콜이 고레이지 지연 링크에서 SSH보다 훨씬 빠를 거라 생각함, UDP기반이라 ack 기다리지 않고 대량 데이터를 연속 전송할 수 있기에 세계 각지에서 큰 파일 scp할 때 상당한 속도 향상을 기대함
VPN 위에서 진짜 빠를 수 있음, "TCP 안에 또 TCP"라는 덫(성능문제)이 없어서임
HTTP/3, QUIC 전체의 주된 장점이 기존 대비 라운드트립 감소, 그래서 연결 설정이 더 빨라지는 것과 일맥상통함
“SSHv2로는 세션 초기화에 5~7번 정도 라운드트립이 필요한데, SSH3에서는 3번만 필요함. 실제 세션 동안 입력 지연(키 입력–반응 시간)은 동일함”이라는 설명이었음. 사용자 입장에선 연결 속도가 크게 신경 쓰인 적 없어 매력을 못 느끼겠음. SSH는 전투적으로 검증된 안정성도 있고, 이런 새 도구가 실제로 프로덕션급이라 할지라도 신뢰하기에 리스크가 큼
UDP 터널이 핵심 기능임, wireguard보다 훨씬 가볍고 OpenID 인증 같은 것도 있음
‘연결 속도’가 항상 나를 조금은 괴롭힘. 원격에서 커맨드를 바로 실행할 때 느린 것이 특히 아쉬웠음
ssh3에서는 헤드오브라인 블로킹이 해결되었을 가능성이 높음, 한 물리연결에서 여러 포트나 연결을 멀티플렉싱하면 더 빠를 것임
모든 어플리케이션 레이어 프로토콜이 http에 흡수되는 게 왜 이리 슬픈 느낌인지 모르겠음
정말 그런 흐름이라면 슬플 것 같음, HTTP 전형적 모델이 대부분 경우 너무 제약적이면서 복잡해서 많은 곳에 안 맞음. 그런데 HTTP/2나 QUIC(HTTP/3의 트랜스포트)는 너무 범용적이라 HTTP라는 명칭 자체가 큰 의미가 없어지는 듯함. 최소한 QUIC는 TCP 대체제로 꽤 명확히 포지셔닝해서 씀
사실 이렇게 모든 프로토콜이 표준화되면 트래픽 쉐이핑, 검열 등이 어려워서 긍정적으로 생각함. 결국 트래픽이 HTTP거나, 랜덤 바이트 스트림이면 (즉, 눈에 띄지 않으면) 네트워크 감시/차단이 어려움. 새로운 프로토콜을 만든다면, 통신사가 뭔가 특별히 유리하게 해주지 않는 이상, HTTP로 위장하는 게 느려지지 않고 잘 다니는 방법임
이런 현상은 기업 보안팀이 뭐든 죄다 차단하거나 가로막으려 하는 관행 탓임. Zscaler나 TLS 미들맨 모드 쓰는 팀 너희 말하는 거임
이런 식의 차단은, 공항 와이파이나 전 세계 호텔에서도 나타남. 예를 들어 Apple Mail로 메일이 안 간다거나 하는 이유도 기업 방침으로 25번 포트를 막기 때문임. 스팸 막는다면서 143, 587, 993 등 다 막아서 결국 80, 443만 통과 시킴. IPv6가 좀 나아지길 바람. 그리고 EU의 ChatControl 추진 같은 일은 멈췄으면 함. 진짜 IT를 아는 사람 말을 좀 들어줬으면 함
connection init, 즉 망 연결 초기화 복잡성이 높아져서 결국 battle-tested 프로토콜 기반 best practice에 올라가야 하는 것도 이해는 감. 그런데 실제 전송은 더이상 hypertext가 아닌 상황에서 계속 http라 부르는 게 어색한 느낌임
SSH 기능 자체가 진화하는 건 멋진 일인데, 어차피 거의 새로 만드는 작업이라면 좀 더 실험적인 새 기능도 넣었으면 하는 아쉬움임. 예를 들어 Mosh 같은 “로밍/일시적 네트워크 불안정” 대응 같은 편의 기능 있으면 좋겠음 https://mosh.org/
Mosh의 장점은 키 입력 반응 무지 빠르고, 마치 로컬 셸에 직접 작업하는 것 같은 느낌임. SSH3는 이런 부분 개선은 없나 궁금함. QUIC가 약간은 보완하겠지만, Mosh와는 또 다름
내 이해로 connection migration이나 multipath 지원은 QUIC의 기본 특성이며, roaming 기능과 '내장 tmux'의 차이는 그게 시스템에 직접 녹아든 것이 진짜 가치가 있는지는 잘 모르겠음
짧은 명칭/약어에 집착하는 사람들이 궁금함, 정말 별로임. 이제는 명령어가 길어도 되니 최대한 기술적으로 명확한 긴 이름을 써야 한다고 생각함. 풀네임을 기본으로 쓰고 약어는 일부 시스템 관리자나 배포판에서 줄여서 써도 됨. 사람들에겐 풀네임을 가르쳐야 함. 예를 들어 Set-Location이 cd 대신 더 바람직함, remote-terminals-over-http3 같은 이름이 ssh3보다 좋음
마지막 커밋이 1년 전인데, 혹시 프로젝트 최근 진행 상황 아는 사람 있음?
프로젝트 계획이 궁금해짐. 릴리즈나 깃허브 활동 모두 1년 넘게 소식 없음. 논문부터 시작한 방식이니 관련 연구나 다른 부수 작업을 계속하고 있을 수도 있다고 생각함
이 포인트 지적해줘서 고마움. 개인적으로는 이 프로젝트 이제 끝났다고 판단함. 239커밋 정도로 사실상 Proof of Concept 수준이라 아직 진지하게 쓸 만한 게 아님. 반면 OpenBSD 쪽(OpenSSH)는 여전히 엄청 활발하니 아직 충분히 대체될 여지는 없어 보임 https://github.com/openbsd/src/commits/master/
프로젝트 아이디어는 괜찮음. 일반 H3 프록시로 프록싱이 가능하다면 특히 기대됨. 거기에 multipath/migration, TCP 관련 블로킹 이슈까지 해결한다면 이미 엄청난 발전임
Hacker News 의견