[CS] 네트워크

jy9922·2022년 9월 9일
CS
0

취업준비

목록 보기
3/3

Network

OSI 7 Layer

1계층 : 물리 계층

  • 전기적, 기계적, 기능적 특성을 이용해 통신
  • 통신 단위 : 0과 1
  • 단지 데이터 전달만 ( 에러확인X )
  • 장비 : 통신 케이블, 리피터, 허브

2계층 : 데이터 링크 계층

  • 정보의 전달 수행
  • 통신 오류 찾음, 재전송
  • 맥 주소(물리적 주소)를 가지고 통신
  • 오류제어, 흐름제어 필요
  • Protocol
    • 이더넷, 포인트 투 포인트, HDLC. ADCCP
  • 장비 : 브리지, 스위치

3계층 : 네트워크 계층

  • 데이터를 목적지까지 안전하고 빠르게 전달
  • 주소부여(IP), 경로설정(Route)
  • 라우팅, 흐름제어, 세그맨테이션, 오류제어, 인터네트워킹 수행
  • IP 계층 : IP 패킷의 전달 및 라우팅 담당
  • Protocol
    • IP 패킷의 라우팅 대상, IP주소 지정 / 패킷의 전달 -> IP
    • 패킷 전달 에러의 보고 및 진단 -> ICMP
    • 복잡한 네트워크에서 경로 찾기 -> 라우팅
  • 장비 : 라우터

4계층 : 전송 계층

  • 포트를 열어서 응용프로그램들이 전송
  • 양 끝단의 사용자들이 신뢰성있는 데이터를 주고 받을 수 있도록 해줌 -> 상위 계층들이 데이터 전달의 유효성, 효율성 생각X
  • 상태 개념(stateful), 연결 기반 (connection oriented)
  • 패킷들이 유효한지 확인하고 전송 실패 패킷은 재전송
  • protocol
    • TCP : 신뢰성, 연결지향적
      • 패킷 손실, 중복, 순서바뀜이 없도록 보장
      • 이메일, 파일 전송 (순서대로 도착)
    • UDP : 낮은 신뢰성, 비연결성
      • 확인 응답X, 순서제어X, 흐름제어X
      • 실시간 응용 및 멀티캐스팅
      • 이미지, 실시간 동영상, DNS, 게임

5계층 : 세션 계층

  • 데이터가 통신하기 위한 논리적 연결
  • 응용 프로세스가 통신을 관리하기 위한 방법 제공

6계층 : 표현 계층

  • 코드 간의 번역을 담당
  • MIME 인코딩, 암호화
  • 사용자의 명령어를 완성 및 결과 표현
  • 포장/압축/암호화

7걔층 : 응용계층

  • 통신 패킷들은 프로토콜에 의해 처리
  • 응용 서비스 수행
  • 네트워크 소프트웨어 UI, 사용자의 입출력
  • protocol
    • HTTP, FTP, SMTP, POP3, IMAP, Telnet

허브 vs 스위치 vs 라우터 vs 공유기

  • 허브
    • 물리계층에서 동작
    • LAN 구성시, 각각의 PC에 연결된 노드를 한 곳으로 모으는 역할 (네트워크 형성)
    • 패킷을 받으면 연결된 모든 장치에 모두 보냄
    • 단순 분배를 하는 중계 장치
  • 스위치
    • 데이터 링크 계층(2계층)에서 동작
    • 자신에게 연결된 디바이스들의 MAC 주소와 포트가 기록된 MAC 주소 테이블을 가지고 있음
    • 정보를 주고 받을 수 있음
    • MAC 주소를 가진 장비가 연결된 포트로만 프레임 전송
      ( BUT, 자신의 테이블에 없는 목적지를 가진 패킷이 오면 해당 패킷을 연결된 모드 장치에 포워딩 -> 허브와 동일한 동작 )
  • 라우터
    • LAN을 연결해주는 장치

허브는 다른 모든 포트에서 허브로 들어오는 모든 트래픽을 보내느 간단한 장치, 이로 인해 네트워크에서 불필요한 트래픽 흐름이 많이 발생하여 충돌 발생 가능성이 있음
(소규모 네트워크에 적합)

스위치는 연결된 장치에 대한 정보를 수집하고 관련 포트를 통해서만 들어오는 트래픽을 전달함
스위치에서 동시 통신을 유지할 수 있음
(대규모 네트워크에 적합)

HTTP의 GET과 POST

  • 서버에 무엇인가 요청

GET

  • 요청 데이터가 HTTP Request Message의 헤더 부분에 url이 담겨 전송
  • ? 뒤에 데이터
  • 데이터가 url에 그대로 노출

POST

  • 요청 데이터가 HTTP Request Message의 Body 부분에 데이터 담겨 전송
  • 데이터 크기가 크고, 보안에서 나음

GET vs POST

GET

  • 서버의 값 혹은 상태 변경 X
    • SELECT 적인 성향
  • 브라우저에서 Caching 가능

POST

  • POST는 서버의 값이나 상태를 변경 혹은 추가하기 위해 사용

TCP 3-way Handshake

연결 성립 (TCP 3-way Handshake)

  • 클라이언트는 서버에 접속 요청 SYN(a) 패킷 발송
  • 서버는 요청을 받고 수락하는 ACK(a+1)과 SYN(b) 패킷 발송
  • 클라이언트는 서버의 패킷을 받고 ACK(b+1) 패킷 발송

연결 해제 (TCP 4-way Handshake)

  • 클라이언트가 연결 종료하겠다는 FIN 플래그 전송
  • FIN을 받은 서버는 확인 메세지로 ACK
    • 데이터를 모두 보낼 때까지 잠깐 TIME_OUT
  • 통신이 끝나면 연결이 종료되었다고 FIN 플래그 전송
  • 클라이언트는 FIN 메세지 받음 -> ACK 발송
  • 서버는 ACK 메시지 받고 소켓 연결 close
  • 클라이언트는 아직 서버로부터 못 받은 데이터가 있을 것을 대비해 일정시간동안 세션을 남겨놓고 잉영 패킷을 기다리는 과정 (TIME_WAIT)

TCP와 UDP

UDP (User Datagram Protocol)

  • 비연결형 프로토콜
  • 흐름제어, 오류제어, 세그먼트의 수신에 대한 재전송 X

TCP (Transmission Control Protocol)

  • 바이트 스트림을 전송
  • 송신자, 수신자 모두 소켓
  • 3-way handshake를 통해 행해짐
  • 전이중, 점대점 방식
  • 멀티캐스팅, 브로드캐스팅 지원 X

HTTP와 HTTPS

HTTP

  • 포트번호 80

HTTP 의 문제점

  • 평문 통신 -> 도청 가능
  • 통신 상대 확인 X -> 위장 가능
  • 변조 가능

TCP/IP는 도청 가능

통신 경로 상에서 패킷을 수집해 도청 가능함
암호화 통신 필요

보완

  • 통신자체 암호화 SSL(Secure Socket Layer), TLS(Transport Layer Security)를 조합해 HTTP 통신 암호화 -> SSL + HTML = HTTPS ( HTTP over SSL )
  • HTTP 메세지에 포함되는 콘텐츠만 암호화, 암호를 해독해서 출력하는 처리 필요

통신 상대를 확인하지 않기 때문에 위장 가능

  • 상대가 누구인지 확인하는 처리 X -> 누구든지 request 가능
  • 접근 제한이 없는 경우라면, 서버는 누구든지 response 반환

보완

  • SSL로 상대 확인
  • SSL은 상대를 확인하는 수단으로 증명서 제공
  • 증명서는 제 3자 기관에 의해 발행됨
    • 서버나 클라이언트가 실재하는 사실을 증명함
  • 개인정보 누설 줄어듦

완전성을 증명할 수 없어 변조 가능

  • 완전성 = 정보의 정확성
  • 서버 or 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없음
  • 공격자가 도중에 request나 response를 빼앗아 변조하는 것을 중간자 공격이라고 함

보완

  • MD5, SHA-1 등의 해시 값을 확인하는 방법
  • 파일의 디지털 서명을 확인하는 방법
  • HPPS 사용 (SSL은 인증, 암호화, 다이제스트 기능 제공 )

HTTPS

HPPT에 암호화, 인증, 완전성 보호를 더한 것 (포트 : 443)

  • HTTPS는 SSL의 껍질을 덮어쓴 HTTP
  • HTTP 통신하는 소켓 부분을 SSL or TLS라는 프로토콜로 대체하는 것
  • HTTP는 TCP와 직접 통신, HTTPS는 SSL과 통신하고 SSL이 TCP와 통신
  • SSL은 공통키 암호화, 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템 사용

    모든 웹 페이지에서 HTTPS를 사용해도 될까?

    • 평문 통신에 비해서 암호화 통신은 CPU, 메모리 등의 리소스를 더 많이 요구
    • 통신 할 때마다 암호화를 하면 추가적인 리소스를 소비 -> 처리할 수 있는 request가 상대적으로 줄어듦
    • 하지만 최근에는 하드웨어의 발달로 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 X
    • HTTP 2.0을 함께 이용한다면 HTTP보다 더 빠르게 동작
    • 현재 모든 웹 페이지에서는 HTTPS를 적용하는 방향으로 바뀌어 가고 있음

SSL handshake

HTTPS는 제3자 인증, 공개키 암호화, 비밀키 암호화를 사용

  • 제 3자 인증 : 믿을 수 있는 인증기관에 등록된 인증서만 신뢰
  • 공개키 암호화 : 비밀키를 공유하기 위해 사용 (RSA, 디프헬만..비대칭키!)
  • 비밀키 암호화 : 통신하는 데이터 암호화하는데 사용
  • 클라이언트는 TCP 3 way handshake 수행 이후 Client Hello 전송
  • 서버는 인증서 보냄
  • 클라이언트는 받은 인증서를 신뢰하기 위해 등록된 인증기관인지 브라우저에서 확인
    • 이 인증서(CA의 개인키로 암호화됨), 클라이언트에서 공개키로 검증
  • 클라이언트는 사이트의 정보, 서버의 공개키 얻음(같이 딸려나온)
  • 서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냄
  • 서버는 이를 개인키로 확인(복호화)하고 이후 통신은 공유된 비밀키로 암호화되어 통신

DNS

  • 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환하는 시스템

DNS Round Robin 방식의 문제점

  • 서버의 수 만큼 공인 IP 주소가 필요함
    • 부하 분산을 위해 서버의 대수를 늘리기 위해서 그 만큼의 공인 IP가 필요
  • 균등하게 분산되지 않음
    • 모바일 사이트 등에서의 프록시 서버는 이름 변환 결과가 일정 시간동안 캐싱됨 -> 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 접속
    • 웹 용 브라우저도 DNS 질의 결과를 캐싱 -> 균등하게 부하분산X
      ( DNS 레코드의 TTL 값을 짧게 설정 -> 어느정도 해소, BUT TTL에 따라 캐시를 해제하는 것은 아니므로 주의 필요! )
      TTL : IP 패킷 내에 있는 값, 그 패킷이 네트웍 내에 너무 오래 있어서 버려져야하는지의 여부를 라우터에게 알려줌
  • 서버가 다운되도 확인 불가 -> 헬스 체크 불가

DNS 스케줄링 알고리즘

  • Weighted Round Robin
    : 각각의 웹 서버에 가중치 가미 분산 비율 변경

  • Least Connection
    : 접속 클라이언트 수가 가장 적은 서버 선택
    : 로드 밸런서에서 실시간으로 Connection 수를 관리하거나 각 서버에서 주기적을 알려주는 것이 필요

웹 통신의 큰 흐름

in 브라우저

  • url에 입력되는 값을 브라우저 내부에서 결정된 규칙에 따라 의미 조사
  • 조사된 의미로 HTTP Requset 메세지 생성
  • 만들어진 메세지 웹 서버로 전송
    • 메세지 전송은 안 이루어지고 OS에 의뢰하여 메시지를 전달함
    • OS에 송신을 의뢰할 때 도메인 명이 아닌 ip 주소로 메세지를 받을 상대를 지정 -> 이 과정에서 DNS 서버 조회

프로토콜 스택, LAN 어댑터

  • 프로토콜 스택 (운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로 메시지 받음
  • 브라우저로부터 받은 메시지를 패킷 속에 저장
  • 수신처 주소 등의 제어 정보를 덧붙임
  • 패킷을 LAN 어댑터에 남김
  • LAN 어댑터는 Hop의 MAC 주소를 붙인 프레임을 전기신호로 변환
  • 신호를 LAN 케이블에 송출

    프로토콜 스택은 통신 중 오류가 발생했을 때, 제어 정보를 사용하여 고쳐 보내거나 각종 상황을 조절

in 허브, 스위치, 라우터

  • LAN 어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착
  • 라우터는 패킷을 프로바이더(통신사)에게 전달
  • 인터넷에 들어감

in 액세스 회선, 프로바이더

  • 패킷은 인터넷의 입구에 있는 액세스 회선에 의해 POP까지 운반
    ( POP : 통신사용 라우터 )
  • POP을 거쳐 인터넷의 핵심부로 들어감
  • 고속 라우터 사이로 패킷이 목적지를 향해 흘러감

in 방화벽, 캐시 서버

  • 패킷은 인터넷 핵심부를 통과하여 웹 서버측 LAN에 도착
  • 방화벽이 도착한 패킷 검사
  • 웹 서버까지 가야하는지 가지 않아도 되는지 판단하는 캐시 서버 존재
    • 굳이 서버까지 가지 않아도 되는 경우를 골라냄
    • 액세스한 페이지의 데이터가 캐시 서버에 있으면 바로 그 값을 읽어냄
    • 페이지의 데이터 중에 다시 이용할 수 있으면 서버에 저장

in 웹 서버

  • 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘김
  • 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트에 회송
  • 왔던 방식대로 응답 메시지가 클라이언트에게 전달

프록시 서버가 필요한 이유

프록시 서버 : 클라이언트가 자신을 거쳐 다른 네트워크에 접속할 수 있도록 중간에서 대리해주는 서버

  • 분산 처리 (캐시, 로드밸런싱) - 캐시된 웹페이지가 있으면 프록시 서버에서 바로 클라이언트에 전송
  • 보안 - 바이러스 검출, 컨텐츠 차단, 웹 서버 방화벽

프록시 서버 사용 시 페이지의 내용과 데이터의 값이 계속 바뀌면?

  • 캐시 만료기한 설정
  • 프록시 서버로 사용자가 요청했을 때 요청 시간이 프록시에서 다운받은 시간에서 만료기한 내이면 프록시에서 다운, 아니라면 다시 실제 서버 요청

ipconfig, ifconfig

시스템 네트워크에 접속되어 있는 인터페이스(NIC)의 설정 상황을 보여주거나 편집하는 유틸리티 명령어

127.0.0.1 과 local host가 무엇을 의미?

  • 루프백(loopback) 혹은 로컬호스트 주소라고 불림
  • 목적지 IP가 127.0.0.1로 설정되면 네트워크 계층은 이 패킷을 외부로 전송 X
  • 자신이 송신한 패킷을 그대로 수신한 효과
  • 자체 IP 할당 작동이라 인터넷 연결 안되도 작동
  • 127.0.0.1 = localhost

port

  • IP Address의 한계 :
    IP 주소만을 이용해 컴퓨터로 데이터를 보낸다면 컴퓨터는 그 데이터를 받지만, 그 데이터가 어느 프로세스에서 처리되어야 하는 것인지 알 수 없음
  • 통신을 해야하는 프로세스는 각각 자신의 port를 가지고 있고, 해당 port를 통해 데이터를 받음
  • port 정보는 TCP 계층에서 추가
  • 자주 사용 : 80(http), 443(https), ftp(20,21), ...
profile
jy9922
이전 포스트

[CS] 자료구조

0개의 댓글