컴퓨터 네트워크 정리
컴퓨터 네트워크
HTTP의 GET과 POST비교
둘 다 http 프로토콜을 이용해서 서버에 무엇인 가를 요청할 때 사용하는 방식
GET
요청하는 데이터가 HTTP request message
의 헤더 부분의 url에 담겨서 전송됨
url 상에 ?
뒤에 데이터가 붙어 request를 내보낸다.
전송할 수 있는 데이터의 크기 제한적
보안이 필요한 데이터는 url에 노출 되므로 적절하지 않다.
POST
request가 HTTP Message
의 바디 부분에 데이터가 담겨서 전송된다.
때문에 데이터의 크기가 get보다 크고 보안 면에서 낫다.
차이점
우선 get은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여주는 용도로 서버의 값이나 상태 등을 변경하지 않는다. select와 비슷하다. post는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다. 또한 get은 브라우저에서 캐싱할 수 있다. 따라서 Post로 요청해야 할 것을 get으로 요청했을 경우 캐싱된 데이터가 응답할 가능성이 존재한다.
TCP 3way-handshake & 4way-handshake
연결 성립, 연결 제어
- 클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다.
- 서버는 SYN(a)을 받고 클라이언트에 요청을 수락한다는 ACK(a+1)와 SYN(b)이 설정된 패킷을 발송한다.
- 클라이언트는 수락응답이 담긴 패킷을 받고 ACK(b+1)을 서버로 보내면 연결이
성립
된다.
연결 해제
- 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다.
- 서버는 클라이언트의 요청(FIN)을 받고 알겠다는 확인 메세지로 ACK를 보낸다.
- 데이터를 모두 보낼 때 까지 TIME_OUT된다.
- 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다.
- 클라이언트는 FIN메세지를 확인했다는 메세지(ACK)를 보낸다.
- 클라이언트의 ACK메세지를 받은 서버는 소켓 연결을 close한다.
- 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨놓고 잉여패킷을 기다리는 과정을 거친다. (TIME_WAIT)
SYN / ACK
SYN : synchronize sequence number ACK : acknowledgement
TCP header 에는 Code bit(Flag bit)라는 부분이 존재한다.
이 부분은 총 6Bit
로 이루어져 있으며 각각 한 비트들이 의미를 갖는다.
Urg-Ack-Psh-Rst-Syn-Fin 순으로 되어있으며 해당 위치의 비트가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다.
SYN > 000010
ACK > 010000
왜 두 종류의 패킷이 필요한가?
연결을 성립하려면 서로 통신이 가능한지를 먼저 파악하기 위해 패킷을 먼저 주고받아야 한다.두 종류의 패킷을 주고받으려면 요청과 응답에 대한 패킷을 주고 받아야하기 때문에 두 종류이다.
2way 가 아니라 3way인 이유
TCP connection은 양방향성 연결이다. 클라이언트에서 서버에게 존재를 알리고 패킷을 보낼 수 있다는 것을 알리듯, 서버에서도 클라이언트에게 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 한다. 따라서 2way handshake로는 부족하다.
왜 시퀀스 넘버는 랜덤인가?
처음 클라이언트에서 SYN 패킷을 보낼 때 시퀀스 넘버에는 랜덤한 숫자가 담겨있다. 초기 시퀀스넘버를 ISN이라고 한다. ISN이 0부터 시작하는 것이 아니라 난수인 이유는 무엇일까? connection을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제를 줄이기 위해 난수로 ISN을 설정한다.
TCP 프로토콜
TCP 프로토콜의 기능은 신뢰성 있는 데이터 전송, 연결 제어, 흐름 제어, 혼잡 제어가 있다.
OS에서는 전송하려는 데이터를 TCP/UDP 세그먼트로 만들 때 헤더를 추가하여 공통적으로 출발지 포트 번호와 목적지 포트 번호를 둔다. 이를 Multiplexing
이라고 하고 목적지에 도착한 세그먼트는 헤더를 확인하여 Demultiplexing
된 뒤 대상 소켓에게 데이터를 전달한다.
적절한 타임 아웃 시간 예측
타임 아웃 시간을 너무 짧게 두면 재전송 요청을 많이 두게 되고 너무 긴 시간으로 두면 기다리는 시간이 길어진다. 적절한 타임 아웃 시간을 설정하기 위한 방법으로 그때그때 확인된 RTT(Round Trip Time)을 이용하여 예측한다.
흐름 제어와 혼잡 제어
- 흐름 제어 : 송신량과 수신 처리량을 일치시키는 것
수신 측이 수신 가능한 양보다 더 많은 데이터를 전송하려 해도 남은 공간이 없다면 전송한 데이터를 버리게 된다.
이를 위해 수신측에서 피드백을 주어야 하는데
stop and wait
방식과Sliding window
방식이 있다. stop and wait는 1개씩 프레임을 전송하기 때문에 효율이 나쁘고 거의 이용되지 않는다. Sliding window는 수신측이 여유 공간 크기를 rwnd(TCP 패킷 헤더의 Window Size 필드)라는 값으로 송신 측에 알려주고 송신측은 rwnd가 넘지 않도록 데이터를 보낸다. - 혼잡제어 : 네트워크가 혼잡하다고 판단될 때 데이터 송신량을 떨어뜨리는 것 라우터의 버퍼가 오버플로우 되어 패킷이 유실되는 경우, 라우터에 버퍼에 대기함으로 인해 평소보다 큰 딜레이가 발생되는 경우
TCP와 UDP의 비교
UDP
UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)
는 비연결형 프로토콜 이다.
IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공한다.
UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다.
UDP가 행하는 것은 포트를 사용하여 IP프로토콜에 인터페이스를 제공하는 것이다.
만약 요청 또는 응답이 손실된다면, 클라이언트는 time out되고 다시 시도할 수 있으면 된다. 코드가 간단하고 TCP처럼 초기설정에서 요구되는 프로토콜보다 적은 메시지가 요구된다.
DNS가 UDP를 사용한 것이다. 어떤 호스트 네임의 IP주소를 찾을 필요가 있는 프로그램은 DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.
TCP
인터넷 분야는 신뢰성과 순차적인 전달을 필요로 한다. UDP로는 이를 만족시킬 수 없으므로 탄생한 것이 TCP다.
TCP(Transmission Control Protocol, 전송제어 프로토콜)
는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송하도록 설계되었다.
TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다.
TCP에서 연결설정은 3-way-handshake를 통해 행해진다.
모든 TCP연결은 전이중(full-duplex), 점대점(point to point) 방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미한다. 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다.
TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.
HTTP와 HTTPS
HTTP의 문제점
HTTP는 평문 통신이기 때문에 도청이 가능하다. 통신 상대를 확인하지 않기 때문에 위장이 가능하다. 완전성을 증명할 수 없기 때문에 변조가 가능하다.
TCP/IP는 도청 가능한 네트워크이다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
보완 방법
- 통신 자체를 암호화
SSL(Secure Socket Layer)
나TLS(Transport Layer Security)
라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화 할 수 있다. SSL을 조합한 HTTP를HTTPS(HTTP Secure)
이라고 부른다. - 콘텐츠를 암호화 HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.
통신 상대를 확인하지 않기 때문에 위장이 가능하다.
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제를 유발한다.
- 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
- 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
- 통신하고 있는 상대가 접근이 허가된 상대인지 알 수 없다.
- 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
- 의미없는 리퀘스트도 수신한다. > Dos 공격을 방지할 수 없다.
보완방법
SSL
로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3 자 기관에 의해 발행되기 때문에 서버나 클라이언트가 실제하는 사실을 증명한다.
이 증명서를 이용함으로써 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인정보 누설 등의 위험성이 줄게된다.
클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에도 이용할 수 있다.
완전성을 증명할 수 없기 때문에 변조가 가능하다.
완전성은 정보의 정확성을 의미한다. 즉, 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일지하는 것을 보장할 수 없다는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 변조되더라도 이 사실을 알 수 없다. 이렇게 공격자가 도중에 리퀘스트나 리스폰스를 변조하는 공격을 `중간자 공격(Man-in-the-Middl)이라고 한다.
보완방법
MD5
, SHA-1
등의 해시 값을 확인하는 방법, 디지털 서명을 확인하는 방법이 있지만 확실하지 않다.
확실한 방지를 위해선 HTTPS를 사용해야 한다.
SSL는 인증, 암호화, 다이제스트 기능을 제공한다.
HTTPS
HTTPS는 SSL을 덮은 HTTP이다. 따라서 HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니다. HTTP의 소캣을 SSL이나 TLS라는 프로토콜로 대체하는 것이다. HTTP는 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.
SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.
모든 웹페이지가 HTTPS가 아닌 이유
평문 통신에 비해 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하다. 따라서 민감정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다.
DNS round robin
하나의 서비스에 여러 대의 서버를 분산시키는 방법 이를 통해 부하를 분산한다.
DNS Round Robin 방식의 문제점
- 서버의 수 만큼 공인 IP 주소가 필요함
- 균등하게 분산되지 않음
- 서버가 다운되도 확인 불가
웹 통신 흐름
주소창에 특정 URL을 입력시키면 일어나는 일
브라우저
- url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 의미를 조사한다.
- 조사된 의미에 따라 HTTP Request 메시지를 만든다.
- 메시지를 웹 서버로 전송한다. 이때 만들어진 메시지전송은 브라우저가 직접하지 않고 os에 의뢰하여 메시지를 전달한다.
프로토콜 스택, LAN 어댑터
- 프로토콜 스택이 브라우저로부터 메시지를 받는다.
- 받은 메시지를 패킷에 저장한다.
- 수신처 주소 등의 제어정보를 덧붙인다.
- 패킷을 LAN 어댑터에 넘긴다.
- LAN 어댑터는 패킷을 전기 신호로 변환시킨다.
- 신호를 LAN케이블에 송출시킨다. 프로토콜 스택은 통신 중 오류 발생 시 제어 정보를 사용하여 고쳐 보내거나 각종 상황을 조절한다.
허브, 스위치, 라우터
- LAN 어댑터가 송신한 패킷은 스위칭 허브를 경유하여 라우터에 도착한다.
- 라우터는 패킷을 프로바이더(통신사) 에게 전달한다.
- 인터넷으로 들어간다.
액세스 회선, 프로바이더
- 패킷은 인터넷 입구의 액세스 회선에 의해 POP(Point Of Presence, 통신사용 라우터)까지 운반된다.
- POP 를 거쳐 인터넷의 핵심부로 들어간다.
- 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러간다.
방화벽, 캐시서버
- 패킷은 웹 서버측의 LAN에 도착한다.
- 방화벽이 패킷을 검사한다.
- 패킷이 웹서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.
웹 서버
- 패킷이 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다.
- 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 전송한다.
- 왔던 방식대로 되돌아간다.
Nagle 알고리즘
TCP는 3-way-handshake 방식으로 신뢰성을 위해 어느정도 비효율을 감수해야한다.
Hello World라는 메시지를 보낼 때 TCP는 H, e, l, l, o … 등 하나씩 메시지를 끊어서 보내야한다.
이 상황에서는 단순한 메시지 전달에서도 네트워크 비용이 막대하게 발생한다는 문제가 있다.
메시지 하나하나의 처리량과 반응속도는 높아지지만 전체 메시지를 통신하기 위해서는 글자수만큼의 네트워크 비용을 소모한다.
또한 통신시 메시지에 별도의 헤더등의 정보를 추가하기 때문에 패킷의 사이즈가 커진다.
이를 Small Packet Problem
으로 정의하고 Nagle 알고리즘을 통해 이를 해결한다.
Nagle알고리즘은 송신에 있어서 버퍼를 둔 뒤 상대방 Host의 window 사이즈를 고려한 후 어느 길이 만큼의 패킷을 한번에 전송하는 기술이다. 이를 통해서는 통신 횟수가 적어져 비용은 감소한다. 하지만 패킷 하나당 처리량이 늘어나기 때문에 속도는 느려질 수 있다.
OSI 7계층
데이터 단위
(세션,표현,응용) 응용 프로그램이 소켓을 통해 보내는 단위 : 메세지 TCP 통신 : 세그먼트 UDP 통신 : 데이터그램 네트워크 계층 : 패킷 데이터링크 계층 : 프레임 물리계층 : 비트
전송 계층
전송 계층에서는 소켓으로 어떻게 데이터를 잘 전달할 것인지 TCP/UDP를 선택해서 OS의 도움으로 프로세스에게 데이터를 전달해준다. 받은 데이터는 응용계층에서 활용한다.
네트워크 계층
전송 계층에서 보내려는 패킷을 목적지 노드까지 도착시키는 것. 중간 라우터를 통한 라우팅, 포워딩, 연결 설정을 담당한다. 라우팅 : 현재 라우터에서 어떤 라우터로 보내는 것이 목적지까지 최적인지 결정하는 것 포워딩 : 라우팅 후 만들어진 포워딩 테이블 기반으로 패킷을 다른 라우터로 포워딩 한다.
라우팅 프로토콜 : 포워딩 테이블을 만들기 위한 프로토콜 인터넷 프로토콜 : 주소 체계를 위한 프로토콜 ICMP 프로토콜 : 에러 메시지를 전달받기 위한 프로토콜
데이터 링크 계층과 물리 계층
데이터 링크 계층 부터는 실제 인터페이스를 통해 데이터 전송이 이루어진다. 데이터 링크 계층에서는 흐름제어, 오류제어, 반이중 전이중 서비스를 제공한다. MAC(Media Access Control) 주소를 사용한다. IP주소와 다르게 네트워크 인터페이스에 할당된 고유 식별자이다. 물리 계층에서는 물리적인 문제로 인해 잘못된 비트가 전송될 경우 감지하는 오류감지 서비스가 있다. 물리 계층에서는 물리적으로 비트를 전송하기 위한 일들을 한다. 이더넷, 토큰 링 등이 포함되며 전기 신호 혹은 광 통신 등이 있다.
세션 계층
세션 계층은 프로세스가 통신을 관리하기 위한 방법에 대한 계층이다. 프로세스가 OS에게서 데이터를 전달받기 위해서는 소켓을 이용한다.
표현 계층
시스템마다 데이터 표현 방식이 다르기 때문에 이를 같은 데이터로 인식하기 위한 처리를 해준다. 압축과 암호화를 서비스한다. TLS(Transport Layer Security) 직렬화
응용 계층
표현 계층까지 거쳐 이해할 수 있는 데이터가 되었다. SMTP(Simple Mail Transfer Protocol) > 전자메일 FTP(File Transfer Protocol) > 파일 전송 HTTP(HyperText Transfter Protocol) > WWW 정보 교환
서브넷
IP 주소의 서브넷 부분이 같은 노드들을 모아 서브넷이라고 한다. 중계하는 라우터 없이 물리적으로 연결된 네트워크 망 계층적으로 하위에 존재하는 네트워크이기 때문에 관리상 이점을 가진다.
“223.1.1.0/24” 와 같은 표현은 “223.1.1.0” 주소의 상위 24bit가 서브넷 부분임을 알려주고 “/24”를 서브넷 마스크라고 한다. A클래스 : 8비트 255.0.0.0 B클래스 : 16비트 255.255.0.0 C클래스 : 24비트 255.255.255.0
IP주소
네트워크 환경에서 컴퓨터간 통신하기 위해 각 컴퓨터에 부여된 네트워크 상 주소 “192.168.10.1” : 192.168.10 > 네트워크 주소 (공통적인 부분), 1 호스트ip (유일)
IP는 32자리로 이루어진 2진수
따라서 ip주소의 범위는 2^32 현재는 IPv6로 대체중
IP주소의 클래스
IP주소에는 클래스가 있고 이를 알아야 어디까지 네트워크 영역이고 호스트 영역인지 알 수 있다.
- A클래스
- 0xxx xxxx. ::xxxx xxxx. xxxx xxxx. xxxx xxxx::
- IP주소를 2진수로 표현했을 때 맨 앞자리 수가 항상 0인 경우
- 0.0.0.0 ~ 127.255.255.255
- 1부터 126으로 시작하는 네트워크
- 네트워크 범위 0xxx xxxx > 2^7개 : 1.0.0.0 ~ 126.0.0.0
127은 제외한다
- 호스트 주소 개수 ::xxxx xxxx. xxxx xxxx. xxxx xxxx:: > 2^24 - 2개
- B클래스
- 반드시 10으로 시작
- 128.0.0.0 ~ 191.255.255.255
- 10xx xxxx. xxxx xxxx. ::xxxx xxxx. xxxx xxxx::
- 네트워크 범위 10xx xxxx. xxxx xxxx > 2^14개
- 호스트 주소 범위 ::xxxx xxxx. xxxx xxxx:: > 2^16 - 2개
- C클래스
- 반드시 110으로 시작
- 192.0.0.0 ~ 223.255.255.255
- 110x xxxx. xxxx xxxx. xxxx xxxx. ::xxxx xxxx::
- 네트워크 범위 110x xxxx. xxxx xxxx. xxxx xxxx > 2^21개
- 호스트 주소 범위 ::xxxx xxxx:: > 2^8개
NAT(Network Address Translation)
IP 주소 하나를 갖고 여러 호스트를 관리하는 방법 NAT는 IP주소를 효율적으로 사용하고 내부 장비들의 IP 주소를 숨김으로써 보안상으로도 이점을 가진다. 홀 펀칭 : 내부에서 외부로 나가는 패킷이 발생하지 않으면 외부에서 내부로 들어오는 패킷을 막는 점에서 P2P 연결을 어렵게하는 NAT를 해결하는 기법
ICMP(Internet Control Message Protocol)
호스트와 라우터 사이의 네트워크 계층 정보를 통신하기 위해 사용되는 프로토콜
라우팅 알고리즘
- link state : 최단경로
- distance vector : 모든경로를 저장하지 않고 목적지까지의 거리와 가기위한 방향만을 저장하는 방식
- Hierarchical routing : 인터넷을 Autonomous System(AS) 라는 구역으로 나누어 라우팅
참고
- https://brunch.co.kr/@toughrogrammer/
- https://limkydev.tistory.com/
- https://github.com/JaeYeopHan/Interview_Question_for_Beginner