HTTPS

HTTPS(에이치티티피에스)는 HTTP 통신을 암호화하여 만든 프로토콜이다. HTTPS는 "HyperText Transfer Protocol over SSL"의 약자로서, "http secure" 또는 "http over SSL"이라고도 한다. 여기서 SSL은 "Secure Socket Layer"의 약자이다. 에이치티티피에스라고 읽는다. 포트 번호는 443번이다. 보통 "https://"와 같이 소문자로 쓴다.

개요

HTTPS는 기존 HTTP에 비해 보안성을 강화한 프로토콜이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈(Netscape Communications)는 1994년에 넷스케이프 네비게이터 웹브라우저를 위해 HTTPS를 개발하였다. 원래 HTTPS는 SSL 프로토콜과 함께 사용되었다. SSL이 TLS으로 발전한 시기인 2000년 5월, HTTPS는 공식적으로 RFC 2818에 규정되었다. 전자상거래와 클라이언트-서버 간 의 정보교환 시에 자주 쓰이며 암호화 프로토콜인 SSL 이나 TLS 프로토콜을 사용하여 통신을 주고받는다. 일반적으로 HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않고 전송이 된다는 것이었다. 즉, 데이터가 쉽게 도난당할 수 있다는 것이었는데, 이를 극복하기 위해 HTTPS 프로토콜에 SSL을 사용함으로써 등장하게 되었다. 인터넷 통신이 발달함에 따라 네트워크상에서 발생하는 전자상거래, 은행 기관인증, 개인정보를 담고 있는 데이터는 타인이 쉽게 접근할 경우에는 해킹의 문제가 발생하기 때문에 암호화 프로토콜을 이용하여 통신 프로토콜을 사용하게 되었다. 한편, 네이버나 구글에 접속하여 URL을 보면 왼쪽에 자물쇠 모양이 있는데 이는 HTTPS로 암호화 된 상태를 의미한다.

현재 HTTP/1.1을 대부분 사용 중이지만 구글 계열의 사이트는 HTTP/2와 HTTP/1.1을 동시에 지원하며 점진적으로 HTTP/2로 바뀌는 추세이다. HTTP/2는 HTTPS 연결에서만 작동하며, HTTP 연결일 경우에는 브라우저와 서버에서 HTTP/2를 지원하더라도 HTTP/1.1로 연결된다. HTTP/2는 구글이 발표한 비표준 개방형 네트워크 프로토콜인 SPDY 기술을 기반으로 했는데, HTTP/3에도 구글이 발표한 QUIC(Quick UDP Internet Connections) 프로토콜 기술이 적용된다. HTTP/2까지는 TCP 연결을 기반으로 하는데, HTTP over QUIC(HTTP/3)은 UDP 연결을 기반으로 한다. 인터넷에서 일어나는 금융거래 및 전자상거래, 데이터 정보의 통신프로토콜의 발달로 개인의 프라이버시가 중요해짐에 따라서, 구글 크롬과 같은 웹브라우저들은 HTTP 웹사이트를 위험성이 있다고 경고문을 표시하고 있다. 국내기업 중 네이버㈜와 다음이 TTPS를 점차 확대하고있다.

역사

• 1996년 : 첫 상용화 버전인 HTTP/1.0 발표
• 1999년 : HTTP/1.1 발표
• 2015년 : HTTP/2 공식발표

특징

동작원리

응용계층에서 동작하는 HTTP는 TCP/IP(4계층)과 통신을 주고받기위해 소켓을 이용하게 된다. 사실 TCP 계층과 응용계층 사이에는 어떠한 계층이 존재하지 않는데, HTTPS 프로토콜은 이 두 개의 계층 사이에 SSL 계층이 포함되어 있다. 즉, HTTPS는 SSL 위에서 프로토콜이 실행된다. SSL은 일종의 독립적인 보안 계층으로 프로토콜을 실행하는데, 그 이유는 서로 다른 계층 간의 통신에서 소켓이 SSL과 연결되어 SSL이 보안 프로토콜 기능을 제안하기 때문이다. 즉 SSL 프로토콜을 적용하면 SSL을 TCP로 인식하고 TCP는 정상적으로 통신이되어져 HPPTS 프로토콜을 실행하는데 아무 문제가 없다. HTTPS는 HTTP 헤더와 요청·응답 데이터를 비롯한 모든 메시지 내용을 암호화한다.

• SSL : 전송 계층을 보안하는 프로토콜로 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. TLS(Transport Layer Securtiy)라고도 부르며 이는 SSL이 표준화가 됨에 따라 이름이 변경되었다. 이 규약은 인터넷같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단 간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, VoIP 같은 응용 부분에 적용되고 있다. 처음 만들어진 1.0버전이 보안 문제로 취약하여 보안 문제를 극복하기 위해 새로운 버전을 출시했으며 결국 3.0 버전이 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deprecate)으로 간주하여 TLS 1.0을 만드는데 참조가 되었다. 최종 갱신은 RFC 5246이고, 최종 갱신 버전은 넷스케이프에서 만든 SSL 표준을 바탕으로 했다. 보안성을 가진 프로토콜로 인증기관을 통해 가고자 하는 서버의 인증서를 받게 되면 클라이언트의 정보를 암호화하여 전달하는 역활을 한다.

서버설정 및 암호화

HTTPS 연결을 허용하기에 클라이언트는 본인이 접속하는 서버가 신뢰할만한 서버인지 확인을 해야 하는 데 이 신원을 보증하기 위해서는 제3자의 입장인 인증기관(Certificate Authority)을 필요로 한다. HTTPS를 연결하기에 서버의 관리자는 공개키와 개인키를 만들고 신뢰할만한 인증 기간에 비용을 지불하고 공개키를 맡긴다. 인증기관은 암호화된 서버의 공개키를 다른 클라이언트와 서버에게 제공 하고 암호화된 공개키를 받은 서버는 해당 클라이언트에 이를 전달한다. 클라이언트는 인증기관을 통해 인증서 리스트를 탐색하게 되고 인증기관의 이름이 같게 되면 해당 인증기관은 공개키를 얻게 된다. 얻은 데이터를 본인만의 개인 키로 복호화한 후 정보를 받게된다. HTTPS HTTPS 암호화 기술의 주요 특징은 다음과 같다.

공개키 암호화 과정

• 기밀성 : 프라이버시로서, 인증되지 않은 제3자가 정보를 읽지 못하도록 정보를 보호하는 역할을 한다. 그 과정에서 듣거나 볼 수 있는, 보통 평문이라고 하는 읽을 수 있는 정보 형식을 암호문이라고 하는 뒤죽박죽 읽을 수 없는 데이터 형식으로 변환하는 작업을 거친다. 이 과정을 암호화라고 한다. 암호문을 다시 읽을 수 있는 평문으로 전환하는 반대의 과정을 복호화라고 한다. 정보를 암호화하고 복호화하는 방법에는 서버와 클라이언트 간에 공통된 공개키를 가지는 대칭키 암호화 방식, 인코딩과 디코딩이 다른(암호화하고 복호화하는데 사용되는 키가 다름을 의미) 공개키 암호화 방식 등이 존재한다. 그렇기 때문에 암호화를 하여 사용자의 정보를 보호한다.

• 무결성 : HTTPS로 해결하는 또 다른 문제는 데이터 무결성이다. 즉, 전체 정보가 목적지에 도착했으며, 전송 중에 외부의 공격으로 변조되지 않았음을 보장한다. 정보가 잘 전송되었음을 보장하기 위해 메시지 다이제스트 알고리즘을 사용한다. 교환된 각 메시지의 메시지 인증 코드(message authentication codes, MAC)계산은 암호화 해싱 프로세스다. 즉 데이터가 잘 도착했는지 여부를 암호화된 메시지를 주고받음으로 확인한다.

• 대칭키 : 서버와 클라이언트가 같은 키로 데이터를 통신한다. 흔히 암호화 알고리즘이라 부르는데, 암복호화 시 간편하고 드는 비용이 적다. 송수신자 양단은 하나의 키를 사용하여야 하며 이 대칭키는 하나의 키로 암호가 되어있기 때문에 보안상 유출이 된다면 암호의 내용이 해커에 의해 복호화된다는 치명적인 단점을 가지고 있다. 이를 보안을 유지하기 위해 나온 방법이 비대칭키 암호화 방식이다.

• 비대칭 키 : 공개키, 비공개키 방식을 가지고 데이터를 암복호화한다. 공개키로 암호화를 한다면 비공개키로 복호화를 해야 하고 마찬가지로 비공개키로 암호화를 한다면 공개키로 복호화를 해야 한다. 이 방식을 사용하여 두 개의 키 중 하나는 비공개키 혹은 개인키, 보안키(secure key)라고 하며 나머지를 공개키라고 부른다. 비공개키는 사용자 호스트만이 알고 읽을 수 있고 공개키는 다른 사용자에게 제공한다. 이러한 방식을 사용하여 공인 인증기관를 이용하여 인증서를 주고받아 원활한 HTTPS 동작을 수행한다.

인증서

클라이언트가 서버에 접속하기 위해서는 먼저는 본인이 접속하려는 서버가 인증이 보장되는지 판단을 내려야 하는데 이때 인증서에 등록된 정보를 가지고 인증기관에 공개키를 요청하게 된다. 이를 인증서를 통한 인증과정이라 한다. HTTPS는 보안 프로토콜로서 서버의 접속자와 서버 간의 주고받는 데이터의 암호화가 필수인데 이를 지정하고 인증서를 보관하는 인증기관은 신뢰성이 매우 우수해야 하며 정확한 절차로 인증이 된 공인 기업들만이 참여한다. 만약 웹 개발자가 서버를 만들 게되면 공개키를 믿을 수 있는 인증기관에 맡기게 된다. 인증기관은 공개키를 가지고 인증서를 만들고 이를 암호화하여 서버에게 전달한다. 인증서의 절차는 아래와 같은 방식으로 진행된다.

1. 클라이언트는 서버로부터 받은 인증서가 인증기관에 의해 발급이 된 여부를 먼저 파악하기 위해 클라이언트 내에 저장된 인증기관 리스트를 컨펌한다.
2. 컨펌이 된다면 해당 인증기관의 공개키로 인증서를 복호화 하고 이는 비공개키로 암호화됨을 의미한다.
3. 이러한 방식으로 인증서를 전송한 서버를 신뢰하게 된다.

한마디로 말하면, 인증서의 역할은 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장하고 SSL 통신에 사용할 공개키를 클라이언트에게 제공하는 것이다. 인증서를 발급한 기관명, 서비스 및 도메인 정보, 서버 측 공개키, 공개키의 암호화 방법 SSL 인증서 안에 기록되어 있다.

통신방법

설명

컴퓨터와 컴퓨터간에 통신 방법에는 쓰리 핸드쉐이크(3-Handshake) 방식이 사용되며 핸드쉐이크 => 세션 => 세션종료로 진행한다. 핸드쉐이크는 악수라는 뜻인데, 사람사이에서도 먼저 악수를 하며 인사한다. 이를 통해 상대방의 분위기나 기분을 파악 할 수 있고 서로 원활한 커뮤니케이션을 할 수 있다.

• 핸드쉐이크 클라이언트와 서버는 서로 정보를 주고받기 전에 SSL 인증서를 먼저 주고받는다. 서로 간에 암호화 방식이 다를 수 있음으로 협상, 즉 동기화를(synchronization) 맺는 단계이다. 클라이언트가 암호화 방식을 서버에 발신하면 서버는 이를 받고 본인도 사용할 수 있는 암호화 방식을 택하여 다시 클라이언트에게 ACK(응답)와 SNY(동기화)를 보낸다. 이는 동기화를 하기 위한 과정이라고 할 수 있다. 클라이언트는 서버로부터 응답을 받게 되고 협상을 마치게 된다.
• 세션  : 실제 데이터가 오가는 동작 상태를 말한다. 앞서 암호화 방식에 대한 동기화를 했기 때문에 대칭키,비대칭키 방식으로 암호화된 정보를 주고받는다.
• 세션종료 : 주고받을 데이터가 없을 때에 세션을 종료하게 된다.

비교

HTTPS URL은 기본적으로 "https : //"로 시작하고 포트 443을 사용하지만 HTTP URL은 기본적으로 "http : //"로 시작하고 포트 80을 사용한다. SSL 인증서를 통해 사용자가 사이트에 제공하는 정보를 암호화하는데, 쉽게 말하면 데이터를 암호로 바꾸는 의미이다. 이렇게 전송된 데이터는 중간에서 누군가 훔쳐낸다고 하더라도 데이터가 암호화되어있기 때문에 해독할 수 없다. 한가지 예를 들면 512 비트(평균적으로 128비트 암호화)의 암호화라면, 2의 256승을 대입해야하며, 이것은 1,237,940,039,285 ....000(중략)이라는 기하급수적인 수를 대입해야 한다는 뜻과 같다. 그렇기 때문에 현재까지 나온 컴퓨터라 해도 적게는 몇백 년, 많게는 몇천 년 까지 계산을 해야 되는 문제가 발생한다. 그 외에도 HTTPS는 TLS 프로토콜을 통해서도 보안을 유지하고 TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하며, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공한다. 서버-클라이언트 간의 데이터 송수신 시 암호화와 복호화 과정을 통해 데이터를 주고받기 때문에 HTTP보다 신뢰성이 뛰어나긴 하지만 여기서 발생하게 되는 데이터의 자원 소모가 발생하여 통신속도가 HTTP보다 느리다. 흔히 보안성이 낮아도 되는 온라인 뉴스나 기사에 HTTP를 사용하고 금융과 관련된 보안업무나 개인의 데이터 보호에 많이 사용된다.

문제점

HTTPS의 문제점은 사용 시 반드시 증명서를 구입해야 한다는 것이다. 증명서의 구입 비용이 부담되는 서비스나 개인 웹사이트의 경우 HTTP만 선택하기도 한다. 그리고 HTTPS를 사용할 경우 처리가 늦어지게 되는 단점이 있다. 그 이유는 클라이언트 요청 시, SSL에 필요한 통신이 추가되고, 암호화 복호화 계산을 하므로 서버나 클라이언트의 리소스를 추가적으로 소비하기 때문이다. 인증기관은 매우 엄격하고 공인으로 인증된 기업이여햐만 한다. 신뢰성이 없는 인증기관이라면 인터넷 접속 시 SSL 인증서 발급은 물론 사용자와 서버가 서로 주고받는 정보가 도청, 간섭, 방해를 받아 데이터를 손실 할 수 있기 때문이다.

사이버보안 업체인 파이어아이(FireEye)는 최근 2019년 HTTPS를 이용한 피싱 이메일 공격이 17%증가 하였고, URL 기반 공격이 26%상승 했다고 이메일 위협 보고서를 발표했다. 일반적으로 피싱 이메일은 자격 증명 정보나 신용카드 정보를 탈취하기 위한 목적으로, 기존에 알고있는 연락처나 신뢰할 수 있는 회사를 사칭하여 이메일 수신인이 임베디드 링크를 클릭하도록 유도한다.

이런 보안상의 문제를 해결하기 위해 정부는 HTTPS 사이트 접속 차단 조치를 내렸다. 이에대해 성균관대학교 지성우 법학 교수는 "온라인상의 불법 정보를 차단하는 일은 좋은 목적에서 시행한다 해도, 표현의 자유(인터넷의 속도성 자유성 개방성 제한)를 의식해야 한다" 고 말했다. 이런 논란으로 인해 반대하는 국민들과 정책을 시행하려는 정부 측의 의견이 엇갈리고 있다.

물론 정부가 HTTPS 사이트 접속을 규제하긴 했다. 최근 기업의 서버/데이터 관리 또한 악성코드의 감염이 많이 일어나고 있고 구글은 HTTPS가 아니면 접근초차 못하게 한다. 하지만 현실은 불법 정보 사이트에 접속하면 http://warning.or.kr/ IP로 연결되어 경고문이 나오는 것을 심심치 않게 볼 수 있다. 이러한 정부의 적극적인 규제에 한때 DNS를 통한 사이트 우회, VPN 방식 등 여러 가지 어플들이 쏟아져 나왔고 해외와 달리 너무 엄격하다는 비난이 거센 적도 있었다. 그래도 과거보단 많은 불법 사이트가 규제되고 보안을 지키는 데 많은 도움이 되었다. 하지만 개인 SNS나 다크웹 을 보면 불법 정보, 동영상 등이 많이 있고 하나하나 IP를 추적해 규제를 가하는데는 어려움을 겪고 있다. IP주소는 굉장히 많기에 하나하나 규제를 가하는 것이 불가능해 보이긴 한다. 하지만 4차 산업혁명 시대에 더 많은 데이터와 통신을 요구하기에 앞으로 HTTPS의 암호화를 강화하고 적용하는 문제가 있다.

참고자료

• HTTP 나무위키 - https://namu.wiki/w/HTTP
• victolee, 〈(HTTPS)HTTPS와 SSL인증서〉, 《티스토리》, 2017-12-11
• 전송 계층 보안 위키백과 - https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88 전송 계층 보안
• 정아마추어 JEONG_AMATEUR, 〈Http와 Https 이해와 차이점 그리고 오해(?)〉, 《티스토리》, 2017-11-5
• Vladislav Denishev, 〈HTTP에서 HTTPS로 전환하기 위한 완벽 가이드〉, 《Smashing Magazine》, 2018-11-13
• 코딩초보 여성계, 〈네트워크 - HTTP/HTTPS 차이점, HTTPS란?〉《티스토리》, 2019-08-01
• 손님1, 〈10. HTTPS란?〉, 《KENDRIC's BLOG》, 2016-04-12
• 길민권 기자, 〈2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑〉, 《데일리시큐》, 2019-07-16
• 김평화 기자, 〈'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"〉, 《머니투데이》, 2019-06-07
• 카피켓, 〈카피켓의 쉬운 암호학〉, 《티스토리》, 2007-12-20
• jm, 〈TCP-(3way handshaking & 4way handshaking)〉, 《네이버 블로그》, 2020-1-28

같이 보기

• 인터넷
• 웹
• HTTP
• TCP/IP
• 프로토콜

이 HTTPS 문서는 인터넷에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷 □■⊕, 모바일, 사물인터넷, 게임, 메타버스, 디자인 인터넷 PC통신 • 그누텔라 • 네트워크 • 다크넷 • 다크웹 • 딥웹 • 무선인터넷 • 슈퍼피어 • 스타링크 • 아르파넷 • 아이투피(I2P) • 엑스트라넷 • 오버레이 네트워크 • 오투오(O2O) • 오프라인 • 온라인 • 온오프라인 • 유선인터넷 • 인터넷 • 인트라넷 • 초고속 인터넷 • 토어(토르) • 표면웹 • 프리넷 • 피투피(P2P) • 하이브리드 피투피(P2P) • 홈네트워크 인터넷 기술 ARP • DNS • FTP • G-클라우드 • HTTP • HTTPS • IPFS • IPv4 • IPv6 • IRC • IRI • ISBN • LDAP • MOIP • OpenSSL • OSI 7 계층 • RFC • RFID • SFTP • SOAP • SSH • SSL • SSO • TCP • TCP/IP • TLS • UCI • UDP • URI • URL • URN • VoIP • 강화 내부 게이트웨이 라우팅 프로토콜 • 검색 • 검색엔진 • 게이트웨이 • 경계 경로 프로토콜 • 내부 게이트웨이 라우팅 프로토콜 • 다운로드 • 데몬 • 라우팅 정보 프로토콜 • 백엔드 • 사물인터넷 • 서버 • 서버-클라이언트 • 서브넷마스크 • 세션 • 스트리밍 • 식별자 • 아이피(IP) • 업로드 • 에듀테크 • 온프레미스 • 원격 프로시저 호출(RPC) • 유비쿼터스 • 인터넷 기술 • 자율시스템 • 정보기술 • 정보통신 • 채팅 • 챗봇 • 최단경로 우선 프로토콜(OSPF) • 쿠키 • 크롤링 • 클라이언트 • 키워드 • 텔넷 • 토폴로지 • 트래픽 • 패킷 • 포털 • 포트 • 프런트엔드 • 프로토콜 • 프록시 • 해시태그 이메일 IMAP • POP3 • SMTP • 계정메일 • 네이버 메일 • 다음 메일 • 센드메일 • 스팸 • 스팸메일 • 스팸필터링 • 아웃룩 익스프레스 • 야후 메일 • 웹메일 • 이메일 • 지메일 • 카카오 메일 • 한메일 • 핫메일 웹 KWCAG • WCAG • 서핑 • 시맨틱 웹 • 오프라인 웹 • 웹 • 웹 1.0 • 웹 2.0 • 웹 3.0 • 웹개방성 • 웹서비스 • 웹접근성 • 웹접근성 인증마크 • 웹주소 • 웹표준 • 웹호환성 • 피드 웹사이트 BBS • GNB • LNB • UI/UX • 게시판 • 관리자 사이트 • 그래픽 사용자 인터페이스(GUI) • 누리집 • 대시보드 • 드롭다운 메뉴 • 랜딩 템플릿 • 랜딩 페이지 • 리더보드 • 마이홈피 • 메뉴 • 모달창 • 미니홈피 • 방명록 • 배너 • 사용자 경험(UX) • 사용자 인터페이스(UI) • 섹션 • 왼쪽메뉴 • 웹기획 • 웹사이트 • 웹페이지 • 인터페이스 • 쪽지 • 커뮤니티 • 탑메뉴 • 탭메뉴 • 템플릿 • 팝업 • 페이지 • 페이지뷰 • 햄버거 메뉴 • 호버 • 홈페이지 • 화면 웹브라우저 넷스케이프 • 모자이크 • 브라우저 • 브레이브 브라우저 • 블록체인 브라우저 • 사파리 • 삼성인터넷 • 스윙 • 엣지 • 오시리스 • 오페라 • 웨일 • 웹브라우저 • 인터넷 익스플로러(IE) • 크롬 • 파이어폭스 • 판도브라우저 인터넷 서비스 구글 • 구글 미트 • 구글챗 • 구글 행아웃 • 깃허브 • 네아로 • 네이버 • 네이버 웹툰 • 네이버 카페 • 넷플릭스 • 다음 • 라이코스 • 레진코믹스 • 메일루 • 멜론 • 바이두 • 바이트댄스 • 비트토렌트 • 빌리빌리 • 빙 • 소리바다 • 스포티파이 • 아마존 웹서비스(AWS) • 애플 • 야후 • 야후재팬 • 얀덱스 • 에버노트 • 에어비앤비 • 왓챠 • 웹소설 • 웹툰 • 유튜브 • 인스타툰 • 인터넷 서비스 • 인터넷카페 • 잼라이브 • 줌 • 카카오 • 카카오 웹툰 • 카카오페이지 • 탑툰 • 텐센트 • 팟캐스트 • 패스 • 페이오니아 • 페이팔 • 해시넷 • 화상통화 • 화상회의 인터넷쇼핑 11번가 • 그립 • 네이버 쇼핑 • 네이버 쇼핑 라이브 • 라이브방송 • 라이브커머스 • 모바일쇼핑 • 스쉐라이브 • 스타일쉐어 • 아마존 • 알리바바 • 오픈마켓 • 옥션 • 온라인쇼핑 • 위메프 • 이베이 • 인터넷쇼핑 • 인터파크 • 전자상거래 • 지마켓 • 징동닷컴 • 카카오 쇼핑 • 카카오 쇼핑 라이브 • 커머스 • 쿠팡 • 쿠팡 라이브 • 타오바오 • 티몬 소셜 네트워크 SNS(소셜 네트워크 서비스) • 구글 블로거 • 네이버 밴드 • 네이버 블로그 • 디시인사이드 • 링크드인 • 마이크로블로그 • 맞팔 • 브런치스토리 • 블로그 • 소셜 네트워크 • 엑스 (트위터) • 웨이보 • 인스타그램 • 트루스소셜 • 티스토리 • 팔로우 • 페이스북 • 플리커 • 핀터레스트 메신저 골프메신저 • 님버즈 • 대화방 • 두레이 • 디스코드 • 딩톡 • 라인 • 라인웍스 • 마이크로소프트 팀즈 • 메신저 • 버디버디 • 스냅챗 • 스노우 • 스카이프 • 슬랙 • 아이씨큐(ICQ) • 왓츠앱 • 웹메신저 • 위챗 • 잔디 • 직톡 • 카카오워크 • 카카오톡 • 카톡방 • 큐큐(QQ) • 탱고 • 텔레그램 • 틱톡 • 페이스북 메신저 • 플로우 도메인 네임서버 • 다국어도메인 • 도메인 • 레지스트라 • 레지스트리 • 아이피 • 인터넷주소 • 인터넷키워드 • 한글인터넷주소 • 후이즈 호스팅 메일호스팅 • 서버호스팅 • 웹호스팅 • 코로케이션 • 클라우드 • 클라우드 네이티브 • 파킹 • 포워딩 • 호스팅 위키 구스위키 • 나무위키 • 노스모크 • 더위키 • 디시위키 • 리그베다위키(엔하위키) • 리브레위키 • 미디어위키 • 바다위키 • 백괴사전 • 아이티위키 • 알파위키 • 엔하계 위키 • 요다위키 • 우만위키 • 위키 • 위키낱말사전 • 위키독스 • 위키문법 • 위키문서 • 위키문헌 • 위키미디어재단 • 위키백과 • 위키스 • 위키엔진 • 위키원 • 위키원드 • 위키트리 • 위키휴가 • 제이위키 • 제타위키 • 중국위키 • 팬덤(위키아) • 한국어 위키백과 • 한국위키미디어협회 • 항공위키 인터넷 사용자 가입 • 가입자 • 강퇴 • 계정 • 관리자 • 네트워크 관리자 • 네티즌 • 누리꾼 • 대기자 • 데이터베이스 관리자 • 등록자 • 디지털 원패스 • 로그아웃 • 로그인 • 방문자 • 방장 • 블로거 • 블록체인 관리자 • 비회원 • 사용자 • 사이트 관리자 • 서버관리자 • 시삽 • 시스템 관리자 • 아이디(ID) • 운영진 • 웹관리자 • 웹마스터 • 유튜버 • 접속자 • 차단 • 최고관리자 • 탈퇴 • 탈퇴자 • 회원 • 회원제 • 휴면 • 휴면계정 인터넷 단체 IANA • ICANN • W3C • 다르파 • 유럽입자물리연구소(CERN) 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반