질문 출처 : https://github.com/jjuyeon/Tech-Interview-Study/tree/main/network
TCP 프로토콜의 특징을 UDP 프로토콜과 비교
https://mangkyu.tistory.com/15
TCP 프로토콜 (Transmission Control Protocol, TCP)
전송 제어 프로토콜. 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나.
특징
- 연결형 서비스(connection-oriented)로 가상 회선 방식을 제공한다.
- 3-way-handshaking 과정을 통해 연결을 설정하고 4-way-handshaking을 통해 해제한다.
- 흐름 제어(수신측에서 오버플로우 안 날 정도로만 데이터 보냄) 및 혼잡 제어(인터넷 상황을 고려해서 데이터를 보냄)
- 높은 신뢰성
- UDP 보다 속도가 느림
- 전이중(Full-Duplex), 점대점(Point to Point) 방식
UDP 프로토콜 (사용자 데이터그램 프로토콜, User Datagram Protocol, UDP)
UDP 전송 방식은 단순하여 서비스의 신뢰성이 낮고, 데이터그램 도착 순서가 바뀌거나 중복되거나 심지어는 통보 없이 누락시키기도 한다. UDP는 일반적으로 오류의 검사와 수정이 필요없는 어플리케이션(주로 비디오, 음성 전송 상황)에서 수행할 것으로 가정한다.
특징
- 비연결형 서비스로 데이터그램 방식을 제공한다
- 흐름 제어, 혼잡 제어 제공하지 않는다.
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
- UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
- 신뢰성이 낮다
- TCP보다 속도가 빠르다
TCP와 UDP 비교
TCP는 데이터를 주고 받을 양단 간에 먼저 연결을 설정하고 설정된 연결을 통해 양방향으로 데이터를 전송하지만, UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다.
- 신뢰성 - TCP는 메시지 수신을 확인하지만 UDP는 수신자가 메시지를 수신했는지 확인할 수 없다.
- 순서 정렬 - TCP에서는 메시지가 보내진 순서를 보장하기 위해 재조립하지만 UDP는 메시지 도착 순서를 예측할 수 없다.
- 부하 - TCP보다 속도가 일반적으로 빠르고 오버헤드가 적다.
프록시와 프록시 서버
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84
프록시
서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것
프록시 서버
클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용프로그램. 프록시 서버 중 일부는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장해 둔다. 이렇게 캐시를 해두고 난 후에 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨으로써 전송 시간을 절약할 수 있게 됨과 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점을 갖게 된다. 또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상을 방지하는 효과도 얻을 수 있다.
종류
- 공개 프록시 (오픈 프록시)
누구나 자유롭게 접속하여 사용할 수 있는 프록시 서버. 공개 프록시를 사용하면 자신의 IP 주소를 남기지 않고 익명으로 활동하기가 쉽기 때문에 이러한 서버들은 크래킹, 악성 코드 또는 바이러스 유포, 불법 행동 등에 악용되기 쉽다. 따라서 많은 프로그램은 공개 프록시를 검출하여 사용을 금지하는 방법을 사용한다.
- 리버스 프록시
컴퓨터 네트워크에서 클라이언트를 대신해서 한 대 이상의 서버로부터 자원을 추출하는 프록시 서버의 일종이다. 그런 다음 이러한 자원들이 마치 웹 서버 자체에서 기원한 것처럼 해당 클라이언트로 반환된다. 관련 클라이언트들을 위해 임의의 서버에 접속하는 중간 매개체인 포워드 프록시와는 반대로 리버스 프록시는 관련 서버들을 위해 임의의 클라이언트가 해당 서버에 접속하는 중간 매개체이다. 널리 보급된 웹서버들은 리버스 프록시 기능을 사용하는 일이 잦으며 취약한 HTTP 기능의 애플리케이션 프레임워크를 보호한다.
- 투명 프록시 (https://blog.daum.net/nordvpn.kr/23)
일반 프록시는 사용자의 요청을 사용자를 대신해 인터넷으로 전달한다. 사용자의 요청은 먼저 프록시 서버로 전달되어 개인IP(Private IP) 주소를 공인 IP(Public IP)로 변경하고 요청했던 목적지로 해당 정보를 전달한다. 프록시는 사용자의 개인IP를 기억하고 있기 때문에 요청에 대한 답변을 받게 되면 다시 사용자에게 해당 정보를 보내게 된다. 이러한 프록시는 일반적으로 특정 소프트웨어 또는 브라우저 확장을 통해 액세스된다.
반대로 투명 프록시(Transparent Proxy)는 클라이언트 측 구성을 필요로 하지 않는다. 이 프록시는 전체 네트워크에 설정되어 있으며 개별 클라이언트에게는 보이지 않는다. 사용자는 자신의 트래픽이 투명한 프록시를 통해 라우팅 되는 것을 인지하지 못할 수도 있다. 일반 프록시와 달리 사용자의 IP를 공인IP로 변경하지 않기 때문에 서버에 대한 요청이 사용자로부터 바로 전달되는 것처럼 나타난다.
사용 목적
- 익명으로 컴퓨터를 유지 (주로 보안을 위하여)
- 캐시를 사용하여 리소스로의 접근을 빠르게 하기 위해. 웹 프록시는 웹 서버로부터 웹 페이지를 캐시로 저장하는 데 흔히 쓰인다.
- 네트워크 서비스나 콘텐츠로의 접근 정책을 적용하기 위해. (원치 않는 사이트를 차단)
- 사용률을 기록하고 검사하기 위해 (회사는 인터넷 이용을 파악)
- 보안 및 통제를 뚫고 나가기 위해
- 바이러스 전파, 악성 루머 전파, 다른 정보들을 빼낼 목적으로
- 역으로 IP추적을 당하지 않을 목적으로
- 전달에 앞서 악성 코드를 목적으로 전달된 콘텐츠를 검사하기 위해
- 밖으로 나가는 콘텐츠를 검사하기 위해 (데이터 유출 보호)
- 지역 제한을 우회하기 위해
HTTP와 HTTPS의 차이
https://www.venafi.com/blog/what-are-differences-between-http-https-0
HTTP (Hypertext Transfer Protocol)
HTTP는 인터넷 네트워크를 통해 데이터(웹사이트 콘텐트, API 요청 등)를 전달하는데 사용되는 프로토콜이다.
HTTP 메세지에는 요청(리퀘스트)과 응답(리스폰스) 두가지가 있다. 만약 사용자가 특정 웹사이트로 이어지는 하이퍼링크를 클릭한다면, 브라우저는 해당 웹사이트에 나타나는 콘텐트에 대한 요청(리퀘스트)를 생성한다. 그 HTTP 리퀘스트는 오리진 서버나 프록시 캐시 서버로 전송이 되고 그 서버에서 HTTP 응답(리스폰스)를 보낸다.
HTTP 요청과 응답은 paintext로 전송되는데 이것의 문제점은 별다른 암호화가 일어나지 않아 그 요청을 주시하고 있다면 누구든 읽어낼 수 있다는 점이다. 만약 웹사이트나 웹 어플리케이션을 통해 비밀번호나 카드 번호 등 민감한 정보가 전송된다면 큰 문제가 된다. 악의적인 사용자가 그 요청/응답 메세지를 읽어낼 수도 있고 심지어는 변경할 수도 있다.
이런 문제점을 보완하여 나온 것이 HTTPS이다.
HTTPS (HTTP Secure, HTTP over TSL, HTTP over SSL ...)
HTTPS는 HTTP에 암호화를 더한 프로토콜이다. HTTPS는 TLS(혹은 SSL)을 사용하여 응답/요청을 암호화하기 때문에, 공격자는 랜덤한 문자열만을 볼 수 있다.
TLS는 공개키 암호화 방식을 사용한다. 공개키는 서버의 SSL 인증서를 통해 모든 클라이언트의 장치와 공유된다. 이 인증서는 Certificate Authority(CA)에 의해 암호화되어 사인을 받고, 각 브라우저는 신뢰할 수 있는 CA의 목록을 가지고 있다. CA에게 서명된 인증서는 신뢰할 수 있는 것으로 입증되고, 해당 도메인에 속하므로 브라우저 주소 표시줄의 녹색 자물쇠 모양이 나타난다.
클라이언트가 서버 연결을 열면 각 컴퓨터는 신원을 확인해야한다. 그래서 이 두 장치는 공개키와 비밀키를 사용해 세션키를 만들고, 더 나아가 둘 사이의 커뮤니케이션을 암호화한다. 모든 HTTP 응답/요청은 이 세션키를 통해 암호화되고 이 통신을 가로채려는 그 누구도 plaintext가 아닌 임의의 문자열만 볼 수 있게 된다.
HTTPS는 통신 암호화 외에도 통신 당사자들을 인증(Authentication)하는 데 사용된다. 인증이란 진짜 사람인지 기계인지 구별하는 것을 의미한다. HTTP에는 신원 확인 과정이 없는데 요즘 인터넷에서 인증은 거의 필수적인 것을 생각하면 별로 좋지 않다고 볼 수 있다.
사람의 신원을 확인하기 위해 주민등록번호가 있는 것처럼 서버의 신원을 파악하기 위해 비밀키가 사용된다. 클라이언트가 origin 서버의 채널을 열 때(유저가 웹사이트를 돌아다닐 때) 비밀키의 소유가 그 서버가 실제로 합법적인 웹사이트 호스트라는 것을 증명해준다. 이것은 인증이 없었을 경우에 받을 수 있는 수많은 공격들(Man-in-middle, DNS hijacking, domain spoofing)을 예방할 수 있다.
HTTP도 많은 장점이 있지만, 성능이나 보안상으로는 HTTPS가 더 낫다. 모든 브라우저에서 HTTPS를 사용할 것을 강력히 권장하고 있는 상황이다.
주소창에 URL을 치고 엔터를 치면 흐름이 어떻게 되나요?
용어 정리
호스트 네임, 도메인 네임
- 호스트 네임 = 컴퓨터의 이름 (사람의 이름)
- 도메인 네임 = 컴퓨터 그룹의 이름 (사람의 성)
- kin.naver.com, mail.naver.com, cafe.naver.com에서 kin, mail, cafe 등은 호스트 네임이며 naver.com은 도메인 네임이 된다. 호스트 네임과 도메인 네임을 합친 것을 FQDN(Fully Qualified Domain Name)이라고 부르며 시스템을 지칭하는 완전한 이름이 된다.
DNS(Domain Name System)
- 계층 구조로 서버의 이름을 저장하는 분산형 데이터베이스.
- 호스트 네임을 IP 주소로 변환해줌, host aliasing, mail server aliasing
- 하나의 서버에 할당된 여러 IP 주소를 고르게 꺼내줌 (load distribution, load balancing)
- PC 브라우저에서 www.naver.com을 입력. 그러면 PC는 미리 설정되어 있는 DNS(단말에 설정되어 있는 DNS를 Local DNS라고 부름)에게 www.naver.com이라는 hostname에 대한 IP 주소를 물어본다.
- Local DNS에는 www.naver.com의 IP 주소가 있을 수도 없을 수도 있다. 만약 있다면 Local DNS가 바로 PC에 IP 주소를 넘겨주고 끝남.
- Local DNS에 www.naver.com의 IP 주소가 없을 경우, Local DNS는 www.naver.com의 IP 주소를 찾아내기 위해 다른 DNS 서버들과 통신을 시작함.
- Root DNS 서버에게 www.naver.com의 IP 주소를 물어봄. (각 Local DNS 서버에는 Root DNS 서버의 정보-IP 주소-가 미리 설정되어 있다)
- Root DNS 서버는 www.naver.com의 IP 주소를 모르기 때문에 Local DNS 서버에게 com 도메인을 관리하는 DNS 서버 주소를 알려줌.
- Local DNS 서버는 TLD DNS 서버에게 www.naver.com의 IP 주소를 물어봄.
- TLD DNS 서버에도 com 도메인 서버도 해당 정보가 없기 때문에 naver.com 도메인을 관리하는 DNS 서버를 알려줌.
- Local DNS 서버는 Authoritative DNS 서버에게 www.naver.com의 IP 주소를 물어봄.
- Authoritative DNS 서버에는 www.naver.com의 IP 주소 정보가 있다!! 그래서 Local DNS 서버에게 www.naver.com의 IP 주소를 (222.122.195.6) 응답해줌
- 이를 수신한 Local DNS는 www.naver.com의 IP 주소를 캐싱하고(이후 다른 장치가 물어보면 바로 응답을 줄 수 있도록), 그 IP 주소 정보를 요청한 단말(PC)에게 전달해 준다.
레전드 정신없음
