주요 분야
인터넷 인프라
‘주요 분야’ 패싯에서 인터넷 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
고별을 기다린 DELE: POP3가 표식과 비가역 삭제를 구분한 방법
서버는 `+OK message deleted`라고 응답한다. 그런데 클라이언트가 `QUIT`를 보내기 전에 케이블이 빠진다. 다음 접속에서 메시지 4는 그대로 남아 있다. POP3는 모순이 아니었다. 긍정 응답은 하나의 세션 안에서 되돌릴 수 있는 표식을 접수한 것이었고, 실제 삭제는 그 끊어진 연결이 결코 도달하지 못한 이후 상태에 속해 있었다.
역사
권한을 기다려야 했던 바이트: IMAP 리터럴이 왕복을 자원 경계와 맞바꾼 방법
IMAP 클라이언트는 `{11}`로 한 줄을 끝내고 다음에 올 데이터가 정확히 얼마인지 알린 뒤 멈출 수 있었다. 그 11옥텟은 늦거나 유실되었거나 TCP 흐름 제어를 받은 것이 아니었다. 서버의 한 글자 응답인 `+`를 기다리고 있었다. 그 멈춤은 카운트를 허가 경계로 바꾸었다. LITERAL+가 멈춤을 없앴을 때 네트워크 왕복 하나는 절약했지만, 서버가 원치 않을 수도 있는 바이트의 비용을 누가 치르는지도 바꾸었다.
역사
바이트 번호가 아니었던 체크포인트: FTP가 파일 재개를 배운 방법
FTP 전송 도중 제어 연결에 `110 MARK ssss = rrrr` 응답이 나타날 수 있었습니다. 그것은 일정 바이트가 도착했다는 뜻이 아니었습니다. 송신 시스템이 이해하는 위치를 수신 시스템이 이해하는 위치와 짝지었고, 응답이 이동하는 동안에도 데이터는 멈추지 않아야 했습니다. "다운로드 재개"가 버튼이 되기 훨씬 전에, FTP는 복구를 하나의 확정 경계에서 두 로컬 의미를 보존하는 문제로 다루었습니다.
역사
빈 쿼리가 모든 사람을 나열하던 순간: Finger가 사람의 접속 상태를 네트워크 응답으로 만든 방법
이름도, 비밀번호도, 명령어도 없이 캐리지 리턴과 라인 피드만 보내면 포트 79의 원격 서비스가 응답했습니다. 원래의 Finger 프로토콜에서 그 빈 줄은 현재 그 호스트를 사용하는 모든 사람을 나열해 달라는 요청이었습니다. 교환은 아주 작았습니다. 그러나 공개될 수 있는 것에는 방, 터미널, 유휴 시간, 전화번호, 심지어 사용자가 직접 쓴 메시지까지 포함될 수 있었습니다. Finger의 이후 역사는, 물어볼 수 있는 공유된 장소가 알 권리까지 공유된 것은 아니라는 사실을 배워가는 이야기입니다.
역사
두 번째 연결이 첫 번째 연결의 소유자를 물었다: IDENT가 사용자 이름의 권한을 어떻게 한정했는가
한 서버는 이미 하나의 TCP 연결을 수락한 뒤, 반대 방향으로 또 하나의 연결을 연다. 그 두 번째 연결에서 두 개의 포트 번호를 첫 번째 호스트에 보내고 좁은 질문 하나를 던진다: 첫 번째 연결을 소유한 로컬 사용자는 누구인가? IDENT는 그 답을 로그에 유용하게 쓰이게 했다. 그 역사는 또한 왜 그 답이 권한 허가로 변할 수 없었는지를 기록한다.
역사
시간이 아니던 시간 패킷: NTP 키스오데스가 거절을 실행 가능하게 만든 방법
이 응답은 익숙한 NTP 패킷 형태를 하고 있고, 클라이언트가 방금 보낸 요청에 속해 있기까지 합니다. 그러나 그 타임스탬프는 시계를 조정하는 데 쓸 수 없습니다. Stratum 0과 네 글자의 코드 `RATE`가 이 패킷을 다른 것, 즉 자신이 보호하려는 프로토콜 안에서 적은 트래픽을 요청하는 서버의 한정된 부탁으로 바꿉니다.
역사
파일은 69번 포트에서 오지 않았다: TFTP가 전송을 선택된 엔드포인트에 묶은 방법
정상적인 TFTP 읽기 전송의 패킷 추적은 작은 의외로 시작합니다. 요청은 UDP 포트 69로 보내지지만, 파일의 첫 블록은 다른 포트에서 돌아옵니다. 이 변화는 드리프트도 아니고 별도의 서비스도 아닙니다. 이것은 프로토콜이 공개 문 대신 전송이 끝날 때까지 유지되는 사적인 엔드포인트 쌍으로 갈아탑니다.
역사
SMTP가 답하지 않는 법을 배운 질문: VRFY는 주소 수락과 디렉터리 공개를 어떻게 분리했나
1982년, 원격 기계는 SMTP 서버에 `VRFY Smith`라고 물어 Fred Smith의 실명과 메일박스를 받을 수 있었습니다. 이 명령은 메일 문제를 검사 가능하게 만들었기 때문에 유용했습니다. 그리고 같은 이유로 위험했습니다. 전송 서비스가 한 번에 하나의 질문씩 공개 디렉터리가 되어 버린 것입니다.
역사
서버가 새 이름을 돌려보냈을 때: UIDPLUS가 IMAP 변경 검증을 만든 방법
업로드는 성공했다. 메시지는 메일함 안에 있었다. 그런데도 클라이언트는 오프라인 장부에 꼭 필요한 한 가지 사실, 즉 서버가 어떤 UID를 할당했는지를 여전히 알지 못했다. UIDPLUS 이전에는 긍정적인 결과가 변경 자체를 확인하면서도 그 변경이 만들어 낸 영속적인 로컬 참조를 감추고 있었다. 프로토콜은 "끝났다"에는 답하면서 "지금 뭐라고 불리는가"에는 답하지 않았던 것이다.
역사
연결을 넘겨버린 명령: SMTP가 TURN을 ETRN으로 대체한 이유
한 메일 호스트가 제공업체에 전화해 회선을 돌려 달라고 요청했습니다. 그러면 서버는 대기 메시지를 같은 연결로 되돌려 보낼 수 있었습니다. 그 편의 뒤에는 권한 이전이 숨어 있었습니다. 호출자는 호스트 이름을 말했을 뿐, 그 호스트의 메일을 받을 자격이 있음을 프로토콜이 증명하지는 못했습니다.
역사
중계가 리셋하지 못했던 기한: SMTP DELIVERBY가 전달한 남은 시간
첫 서버가 받아들인 120초는 다음 서버에서 다시 120초가 되지 않는다. 22초를 소비한 중계는 98초만을 넘긴다. RFC 2852가 표준화한 것은 고속 전달이 아니라, 이 인수 규율이었다.
역사
번호보다 오래 남은 식별자: POP3 UIDL이 클라이언트가 재접속 이후에도 기억하게 만든 방법
월요일에 서버에 남겨둔 메시지는 2번이었다. 화요일 접속 전에 그 앞의 메시지가 사라지면서 같은 항목은 1번이 된다. POP3는 그 세션에 필요한 위치를 이름 지을 수 있었지만, 간헐적으로 접속하는 클라이언트에게는 다른 것이 필요했다. 재접속 후 마주한 메시지가 자신이 이미 저장해 둔 그 메시지라는 근거다.
역사
차단자에게 자신을 밝히라고 요구한 에러 코드
HTTP 451은 법적 장애물을 가시화하고 그를 집행한 주체를 밝힐 수 있었다. 그러나 공개를 강제하거나, 요구를 검증하거나, HTTP 이하의 차단을 노출할 수는 없었다.
역사
마지막 비압축 라인: IMAP COMPRESS가 그 뒤의 모든 바이트를 바꾼 방법
서버의 답장은 평범해 보였습니다. 태그, `OK`, 짧은 확인, 그리고 CRLF. 그 줄이 평범했던 것은 마지막이었습니다. 클라이언트가 IMAP 압축을 요청했다면, 그 다음 서버 옥텟은 더 이상 눈에 보이는 명령 언어에 속하지 않았습니다. 성공한 응답 하나가 살아 있는 연결에서 양쪽 끝이 나머지 바이트를 해석하는 방식을 바꾸어 버렸습니다.
역사
다시 인사해야 했던 인사말: STARTTLS가 SMTP 신뢰를 재설정한 방법
첫 인사말은 암호화되지 않은 채 네트워크를 건너갔습니다. 클라이언트의 이름과 서버의 기능 목록도 마찬가지였습니다. SMTP가 기존 포트를 버리지 않고 암호화를 추가하면서, 프로토콜은 그 대화를 그저 감싸고 원래부터 보호되어 왔다고 가장할 수 없었습니다. 이전에 오간 내용을 잊고 다시 시작해야 했습니다.
역사
메시지에 서명할 수 없던 자격 증명: SMTP AUTH가 제출 신원을 한정한 방법
비밀번호는 메일 제출 관문을 열 수 있었다. 그러나 그 관문을 통과하는 편지에 서명할 수는 없었다. SMTP AUTH가 유용했던 이유는 정확히 프로토콜이 이 명제들을 분리했기 때문이다. 이 클라이언트가 여기서 인증했다. 이 계정은 특정 방식으로 행동할 수 있다. 이 메시지는 발신자를 주장한다. 이 본문에는 작성자가 있다.
역사
다운그레이드될 수 없는 주소: SMTPUTF8이 경로를 이름의 일부로 만든 방법
액센트가 들어간 표시 이름은 ASCII 주소를 감싼 장식이었기 때문에 구형 메일 시스템을 통과할 수 있었습니다. 그러나 비ASCII 메일박스 이름은 다르았습니다. 그것은 그 자체가 수신지이았습니다. SMTPUTF8은 모든 중계 서버가 다른 이름을 만들어내지 않고 그 신원을 운반할 수 있음을 증명하도록 만들었습します.
역사
여덟 번째 비트는 매 홉의 허가를 필요로 했다: 8BITMIME이 바꾼 SMTP
전자우편은 모든 릴레이가 바이트를 그대로 운반할 수 있기 훨씬 전에부터 악센트 문자를 표현할 수 있었습니다. 8BITMIME은 이 불일치를 드러냈습니다. 서버는 해당 홉에서 기능을 약속해야 했고, 수락은 모든 비트를 보존할 의무를 만들어냈습니다.
역사
답이 도착하기 전에 보내진 명령들: SMTP PIPELINING은 어떻게 대기를 바꾸었는가
초기 SMTP는 거의 모든 명령 뒤에 발신 측이 멈춰 기다리도록 했다. 먼 링크에서는 메시지가 실제로 이동하는 시간보다 계속할 허가를 기다리는 시간이 더 길어질 수 있었다. PIPELINING은 그 침묵을 줄였지만, 그 방법은 서술이 아니라 순서를 미완료 작업의 장부로 삼는 것이었다.
역사
오해받기를 거부한 메서드: HTTP 510은 왜 존재했나
RFC 2774는 서버가 필수 HTTP 확장을 무시한 뒤 성공을 반환하는 것을 막으려 했다. 510의 운명은 검증 가능한 의미론이 치르는 비용을 보여준다.