출처: http://sejoong.github.io/dev/2015/02/15/dev/HTTP 2.0 : The New Web Standard and Issue(허태성, saturn.twinfish@gmail.com)

HTTP 1.1 이후로 처음 등장한 새로운 버전인 HTTP/2.0을 알아보기 전에 HTTP가 무엇인지 알아보고 HTTP/2.0에서는 어떤 변화가 있는지 알아보자.

HTTP

HyperText Transfer Protocol의 약자로 WWW(World Wide Web)에서 하이퍼텍스트(hypertext) 문서를 교환하기 위하여 사용되는 통신규약이다.
1.0(1996s)m 1.1(1999s)두가지 버전이 있다.

  • Status code:
    http 통신중 요청의 상태 정보를 제공한다. 공식 적인 상태코드 목록은 IANA에서 확인할 수 있다.
    상태코드의 첫 숫자는 응답의 종류를 나타낸다. 아래는 응답의 종류와 내가 개발중 많이 접했던 몇가지 상태 코드 이다.
  1. 1xx - Informational - 정보교환
  2. 2xx - Success - 성공
    200 - OK - 요청이 성공적으로 전송됨
  3. 3xx - Redirection - 방향 지정
    301 - Moved Permanently - 요청 페이지의 영구적인 위치 변화
    302 - Found - 요청 페이지이 일시적인 위치 변화
  4. 4xx - Client Error - 클라이언트 오류
    404 - Not Found - 요청받은 자원을 서버에서 찾을 수 없을때 나타나는 상태 
    405 - Method Not Allowed - 서버에서 사용자가 요청한 주소의 메소드를 지원하지 않을때 나타남
  5. 5xx - server Error - 서버 오류
  • Request methods:
    요청이 수행될 작업의 방법을 나타낸다.

    1. OPTIONS: 요청한 URL에 어떠한 메소드 요청이 가능한지 묻는다.
    2. GET: 다른 작업없이 데이터의 검색에 이용.
    3. HEAD: 데이터의 검색에 이용하나 GET과는 다르게 응답 HEADER만 받는다.
    4. POST: URL에 새로운 데이터를 보낼때 사용.
    5. PUT: URL에 저장될 정보를 보낸다.
    6. DELETE: URL의 리소스를 삭제한다.
    7. TRACE: 보낸 메세지를 다시 돌려받는다.
    8. CONNECT: 프록시에서 사용되는 예약 메소드.
  • 요청/응답 스펙

Request-Line
*(( general-header | request-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. Request-line: method, request url, http버전
  2. Request-header: general-header, request-header, entity-header가 존재하며 필요에 따라 사용

Status-Line

*(( general-header | response-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. status-line: http 버전, 상태 코드, 상태 메세지
  2. Request-header: general-header, response-header, entity-header

HTTP/2.0의 등장 배경 및 특징

latency를 줄여 웹의 속도를 개선하기 위해 등장.
1. HTTP Header 데이터 압축
2. Server Push(서버에서 부터 시작되는 전송)
3. HTTP 1에서 존재하던 head-of-line blocking 문제 개선
4. 싱글 TCP connection내에서 병렬 페이지 로딩 구현
2.0은 기존 버전인 1.1과의 높은 호환성(method, status codes 등)은 보장하고 클라이언트 서버 간 전송 및 프레임의 개선에 초점을 맞췄다.
head-of-line blocking: 동일한 송신 포트 자원에 대한 처리량 경쟁으로 인해 처리량 지연 및 프레임 손실 발생 유발 작업대기 중인 2개의 패킷이 존재할 경우 첫번째 패킷이 대기중이면 그 뒤 패킷들은 무조건 대기할때 발생












HTTP 2.0의 개선 사항

  1. 효율적인 페이지 로딩을 위해 URL의 이미지, 스크립트등의 자원을 압축해 페이지 렌더링을 위한 요청횟수를 감소시켰다.
  2. 뿐만 아니라 server가 push가 가능해 웹페이지의 렌더링이 필요하단 사실을 알게되면 추가 요청없이 서버가 리소스를 제공한다.
  3. 그 외에도 성능 개선을 위한 요청 다중화, 헤더 압축, HOL Blocking해결을 위한 요청 우선순위 결정등이 있다.

HTTP/2.0과 SPDY와의 관계

  • SPDY:
    Google이 ‘speedy’라는 단어를 기반으로 제안한 새로운 프로토콜이다. HTTP의 단점들을 보완하여, 인터넷 환경을 보다 효율적으로 이용하기 위한 프로토콜이다. HTTP/2.0에서는 스펙에 SPDY를 반영할 예정이다.

  • 특징:

    1. TLS 위에서 동작한다.

      • https에서만 적용가능
    2. HTTP 헤더를 압축한다.

      • 요청마다 반복되는 내용을 압축해 성능 향상 효과가 나타남
    3. 바이너리로 프레임을 구성한다.

      • 파싱 속도가 향상되고 오류확률은 낮아진다.
    4. 다중 연결을 지원한다.

      • 다수의 요청, 응답 을 동시에 처리 할 수 있어 속도 향상
    5. 인터리빙을 허용한다.

      • 우선순위가 높은 데이터가 더 빨리 전송 될 수있다.
    6. 서버 푸시가 가능하다.

결론

HTTP 1.1 이 사용하는 전송방식(RFC7230)에는 몇가지 문제점이 존재했다.
HTTP/1.0은 TCP connection에서 한번에 하나의 요청 만이 가능했고 HTTP/1.1에서는 그보다 발전하여 request pipelining을 사용했지만 여전히 HOL Blocking 문제가 존재했다.
HTTP/2.0은 오랫동안 변화하지 않았던 HTTP를 현 웹 환경에 맞게 발전시켜 속도의 향상을 도모 한다는데 크 의의가 있다.

참고: http://http2.github.io/http2-spec/#intro 참고: http://helloworld.naver.com/helloworld/140351


'Major > Network' 카테고리의 다른 글

HTTP1.0 ~ HTTP2.0  (0) 2016.04.12
http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
  • HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)는 월드 와이드 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다.
    HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다.
    보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다.
    HTTPS를 사용하는 웹페이지의 URL은 'http://'대신 'https://'로 시작한다.

5. HTTPS

SSL은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어다. SSL은 표현계층의 프로토콜로 응용 계층 아래에 있기 때문에, 어떤 응용 계층의 데이터라도 암호화해서 보낼 수 있다.

HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘들다. HTTPS는 SSL 레이어위에 HTTP를 통과 시키는 방식이다. 즉 평문의 HTTP 문서는 SSL 레이어를 통과하면서 암호화 돼서 목적지에 도착하고, 목적지에서는 SSL 레이어를 통과하면서 복호화 돼서 웹 브라우저에 전달된다.

간혹 HTTPS를 하나의 프로토콜로 인식하기도 하는데, HTTP와 SSL은 전혀 다른 계층의 프로토콜콜의 조합이다. HTTPS over SSL로 보는게 좀더 정확한 시각이다. 거의 모든 웹 서버와 웹 브라우저와 HTTP 기반의 툴들 - wget, curlab 기타등등 - 이 SSL을 지원한다.

5.1.1. HTTP와 다른 점

  • HTTPS URL은 "https://"로 시작한다. 기본 포트번호는 443이다. HTTP URL은 "http://"로 시작한다. 기본 포트번호는 80이다.
  • HTTP는 평문 데이터를 기반으로 하기 때문에, 유저정보와 같은 민감한 정보가 인터넷 상에 그대로 노출된다. 이 정보는 수집되거나 변조될 수 있다. HTTPS는 이러한 공격을 견딜 수 있도록 설계돼 있다.
  • HTTPS는 인증서를 이용해서, 접속 사이트를 신뢰할 수 있는지 평가할 수 있다.
  • 일반적으로 HTTPS는 HTTP에 비해서 (매우 많이)느리다. 많은 양의 데이터를 처리할 경우 성능의 차이를 체감할 수 있다. 많은 웹 사이트들이 민감한 정보를 다루는 페이지(로그인 혹은 유저정보) 페이지를 HTTPS로 전송하고, 기타 페이지는 HTTP로 전송하는 방법을 사용한다. 하드웨어 SSL 가속기를 이용해서 암/복호화 성능을 높이는 방법을 사용하기도 한다.

출처: http://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP

'Major > Network' 카테고리의 다른 글

HTTP1.0 ~ HTTP2.0  (0) 2016.04.12
http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
  • 웹 요청에 대한 처리(출처 - 순청향대학교 컴퓨터공학과 이상정)












'Major > Network' 카테고리의 다른 글

HTTP1.0 ~ HTTP2.0  (0) 2016.04.12
http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
  • Datalink Layer Service 
    : 오류 검출 및 정정
    : 브로드캐스트 채널 공유 : 다중 접속
    : 링크 계층 주소체계
    : 근거리 네트워크(LAN) - 이더넷, VLAN
    : 경로 상의 각 링크에서 서로 다른 링크 계층 프로토콜로 데이터그램 전송, 각 링크 프로토콜은 서로 다른 서비스 제공


      

      

  • 오류 검출 및 정정 기술
    - EDC(Error Detection and Correction)
    - 패리티 검사
    - 인터넷 체크섬
    - 순환중복검사(CRC: Cyclic Redundancy Check)


  • 다중 접속 프로토콜 (Multiple Access Protocol, MAC protocol)
  • : 둘 이상의 노드가 동시에 전송하면 충돌이 발생

    - 채널 분할 프로토콜
    (channel partition protocol)

     : 채널을 더 작은 "조각"들로 분할(시간 슬롯, 주파수, 코드)
     : 할당된 조각들은 노드가 배타적으로 사용
     : 높은 부하에서는 효율적이고 공정하게 채널 공유
     : 낮은 부하에서는 비효율적(하나의 활성 노드에 대해서도 1/N 대역폭 할당)
     : TDMA(Time Division Multiple Access), FDMA(Frequency Division Multiple Access), CDMA(Code Division Multiple Access)


    - 랜덤 접속 프로토콜(random access protocol)

     : 채널은 분할하지 않고 충돌 허용
     : 충돌 시 복구
     : 낮은 부하에서는 효율적(단일 노드가 전체 채널 대역폭 사용
     : 높은 부하에서는 충돌 오버헤드
     : 캐리어 센싱(유선에서는 감지 쉽지만, 무선에서는 어려움)
     : 이더넷에서 적용된 CSMA/CD, 802.11에 적용된 CSMA/CA
     : 알로하(ALOHA), 슬롯 알로하(S-ALOHA, slotted ALOHA), CSMA(Carrier Sense Multiple Access), CSMA/CD(Collison Detection), CSMA/CA 

     

     



    - 순번 프로토콜(taking turns protocol)
     : 노드가 순번대로 채널을 사용
     : 더 많은 데이터를 전송하는 노드는 오랫동안 순번을 기다려야 함
     : 두 가지의 장점을 취함
     : 폴링, 토큰 전달
     : 블루투스, FDDI(Fiber Distributed Data Interface)
     
     


  • 근거리 네트워크(LAN)

    - MAC 주소

     

     

    - ARP(Address Resolution Protocol)
     
      ■ 같은 LAN
        

      ■ 다른 LAN으로 라우팅
      
         


  • 이더넷
    : 오늘날 가장 많이 사용되는 LAN 기술
    : 가격 저렴
    : 토큰 LAN이나 ATM보다 더 싸고 간단
    : 빠른 속도
    : 1990년대 중반까지 버스 토폴로지 형태를 사용하다가 오늘날은 중앙에 스위치를 둔 스타 토폴로지 사용(노드간의 충돌이 없음)
     

  • 스위치
    - 허브



    - 이더넷 스위치


    - 라우터 vs. 스위치
     

  • 가상 근거리 네트워크(VLAN)
    :트래픽 격리, 동적 멤버쉽, VLAN들 간의 전달


  • 링크 가상화(MPLS)

     


'Major > Network' 카테고리의 다른 글

http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
네트워크 - Application Layer  (0) 2015.12.02
  • Network Layer
    : transport segment를 발신 호스트에서 수신 호스트까지 보냄
    : sending side는 transport layer에서 segment를 받아 datagrams을 캡슐화
    : receiving side는 transport layer로 datagrams에서 segment를 추출하여 전달
    : 모든 호스트와 라우터에 network layer protocols 내장 
    : 라우터는 입력 링크의 IP datagrams의 헤더 필드를 조사하여 출력 링크로 전달



  • 네트워크 계층의 연결형 및 비연결형 서비스
    - 데이터그램 네트워크(datagram network)는 네트워크 계층에서 비연결형 서비스만 제공
    - 가상회선 네트워크(virtual circuit network)는 네트워크 계층에서 연결형 서비스만을 제공
    - 트랜스포트 계층 서비스와 유사하지만 네트워크 계층 서비스는 다음과 같은 차이
     : 호스트 사이의 서비스
     : 연결형이나 비연결형 서비스 하나만 제공
     : 종단 뿐만 아니라 네트워크 코어의 라우터에서도 구현

  • Two Key Network-Layer Functions
     
    - Forwarding
     : 라우터의 입력 포트에서 출력 포트로 패킷을 이동시키는 것
     : 한 교차로를 지나가는 과정
     : 32비트 IP 주소는 40억개 이상의 주소를 가지므로 라우터 포워딩 테이블이 목적지 주소마다 하나의 엔트리를 갖는다면 아주 큰 테이블이 필요

    - Routing
     : 패킷의 출발지에서 목적지까지의 경로를 얻어내는 것
     : 출발지에서 목적지까지 여행을 계획하는 과정
     ■ 라우팅 알고리즘
      : 링크 상태 라우팅 알고리즘

      

     : 거리 벡터 라우팅 알고리즘
      

     : 계층적인 라우팅
        : 모든 라우터가 동일, 하나의 네트워크로 이상적인 환경으로 가정했지만, 실제는 6억개 이상의 호스트로 인해 확장이 어렵고, 여러 조직의 네트워크가 존재하여 관리 자치권부여에 어려움음 겪음
        

  • Router Architecture Overview

    - Two key router functions
     : 라우팅 알고리즘/ 프로토콜 수행(RIP, OSPF, BGP)
     : 입력 링크를 출력 링크로 포워딩
     

    - Input Port Functions

       


    - Switching Fabric
     
     : memory? 1 세대 라우터, 메모리 대역폭에 따라 속도 제한
     : bus? 버스의 대역폭에 따라 스위칭 속도 제한
     : crossbar? 버스의 대역폭 한계를 극복

    - Output Port Functions


  • IP: Internet Protocol
    - 호스트, 라우터의 네트워크 계층 기능

     

    - IP datagram format
     

    - IP 단편화와 재결합
       

    - IPv4 addressing
         

      ■ Subnet

       

      ■ CIDR(Classless Interdomain Routing)
        : /23, 상위 23비트가 서브넷 주소
      

      ■ DHCP(Dynamic Host Configuration Protocol)
        : 호스트가 네트워크에 접속할 때 서버로부터 IP 주소를 동적으로 획득
        : 네트워크에 연결되었을 때만 주소를 가지므로 주소의 재사용 가능
        : 짧은 시간 동안에 네트워크에 연결되는 모바일 사용자 지원
        : 플러그 앤 플레이 (plug-and-play) 프로토콜
        : 할당된 서브넷 IP 주소 외에 첫 번째 홉 라우터의 주소, DNS 서버의 이름과 IP 주소, 네트워크 마스크 (주소에서 네트워크 호스트의 부분을 표시)

         
              

      ■ ICANN(Internet Corporation for Assigned Names and Numbers)
        : ISP가 주소 블록을 획득받는 곳
        : [RFC 2050]을 기반으로 IP주소 할당
        : DNS 관리, 도메인 이름을 할당하고, 도메인 이름 분쟁 해결

      ■ NAT(Network Address Translation)
       : 지역 네트워크는 외부 세계에로는 하나의 IP 주소만을 사용
       : 모든 디바이스에 대해 하나의 IP 주소만을 사용하여, ISP로 부터 여러 개 주소를 할당 받을 필요 없고, 디바이스의 주소를 변경하지 않고 ISP를 바꿀 수 있음
       : 지역 네트워크 내부의 디바이스들은 외부 세계에서 명시적으로 주소지정을 하거나 노출되지 않음 (보안 이점)

       : 16 비트 포트번호 단일 LAN 측 주소로 6만개 동시 연결
       : 포트번호는 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용되어야 함
       : 라우터는 계층 3까지만 처리해야 함
       : 종단 간의 논의에 위반, 호스트가 IP 주소와 포트번호 수정 없이 직접 통신해야 함

       : 주소의 부족은 IPv6로 해결
       : 횡단 문제 해결로 정적 구성, UPnP, 릴레이
       

         

    - ICMP(Internet Control Message Protocol) 
     : ICMP는 호스트와 라우터 사이에서 네트워크 계층 정보를 통신하기 위해 사용 (오류 보고, 반향 요청/응답)
     : IP 상위 계층으로 ICMP 메세지는 IP 데이터그램의 페이로드로 전송

    - IPv6
     : 32 비트 IP 주소 공간이 빠른 속도로 고갈로 인한 등장
     : 빠른 처리와 포워딩을 지원하는 헤더 포맷, QoS가 용이한 헤더
     ■ IPv6 datagram format
       : 고정된 길이의 40바이트 헤더
       : 단편화(fragmentation)를 허용하지 않음
       : 2128 개로 거의 무한대에 가까운 주소 갯수

        


    - IPv4 vs IPv6
      : 체크섬 제거 -> 각 홉에서의 처리 시간 줄임
      : 옵션 제거 -> 더 이상 표준 IP 헤더 필드가 아닌 IPv6 헤더의 '다음 헤더' 중 하나가 될 수는 있음
      : ICMPv6 -> ICMP의 새로운 버전으로 추가적인 메시지 타입, 코드, 멀티 캐스트 그룹 관리 기능 추가
      : IPv4 -> IPv6로의 전환? 모든 라우터들을 동시에 업그레이드 할 수 없음 -> 터널링을 통해 해결
     ■ 터널링
        
     

  • Routing in the Internet
    : 내부 게이트웨이 프로토콜(Interior Gateway Protocols, IGP)
    - RIP
     : 라우팅 정보 프로토콜(Routing Information Protocol)
     : 거리 측정 (비용 측정) - 홉(hop)의 수, 최대 홉은 15로 제한, 각 링크 비용은 1
     : RIP 라우팅 테이블은 routed(데몬)라는 애플리케이션 계층 프로세스로 구현, 광고는 UDP 패킷으로 주기적으로 반복 전송
      

    - OSPF
     : 개방형 최단경로 우선(Open Shortest Path First)
     : "open"은 라우팅 프로토콜이 공용으로 사용 가능함을 의미, RIP는 주로 하위 계층 ISP나 기업 네트워크 구축에 사용되는 반면, OPSF는 상위 계층 ISP들이 사용
     : 링크 상태의 다익스트라 최소비용경로 알고리즘, 각 노드는 전체 AS의 토폴로지 맵을 가짐
     : OSPF 광고는 인접한 라우터뿐만 아니라 모든 라우터에 라우팅 정보를 브로드캐스트, 링크 상태 정보를 플러딩, TCP나 UDP가 아닌 IP 상에서 직접 OSPF 메시지를 전송
     : RIP에 없는 특징으로 보안, 여러 동일 비용 경로, 여러 비용 측정값, 유니캐스트와 멀티캐스트 통합 지원, 단일 라우팅 도메인에서의 계층 지원

    - IGRP
      : 내부 게이트웨이 라우팅 프로토콜(Interior Gateway Roution Protocol, IGRP), Cisco사 전용

    - BGP
     : 사실상의 인터넷 표준인 인터-AS 라우팅 프로토콜, Border Gateway Protocol
     : 각 AS에게 이웃들로부터 서브넷 도달성 정보, AS 내부의 모든 라우터에게 도달성 정보 전파, 도달성 정보와 AS정책에 근거하여 서브넷으로의 '좋은' 경로 결정
     : 각 서브넷이 자신의 존재를 외부 네트워크로 광고 하도록 함 "I am here"
     : TCP를 사용하여 BGP 메세지 교환 (OPEN, UPDATE, KEEPALIVE, NOTOFICATION)

       
      

  • 브로드캐스트와 멀티캐스트 라우팅
    - 브로드 캐스트
       

    - 멀티캐스트
     


'Major > Network' 카테고리의 다른 글

네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
네트워크 - Application Layer  (0) 2015.12.02
네트워크 - 기본  (0) 2015.12.01
  • Transport services and protocols
    : 서로 다른 호스트의 프로세스간 논리적인 연결 제공
    : 종단 시스템 간에 동작하는 첫번째 layer
    : send side에서 app msg를 segment로 쪼개 network layer로 전송
    : receive side에서는 segment를 message로 재조립하여 application layer로 전송



    - Transport vs. N
    etwork layer
    : Transport는 프로세스간 논리적인 연결
    : Network는 호스트간 논리적인 연결

  • TCP vs. UDP
    : 두 프로토콜 모두 delay, bandwidth guarantees 이용 불가
    : 많은 application들은 하나의 transport layer protocol을 사용하므로 Multiplexing and Demultiplexing이 필요함

    - TCP(Transmission Control Protocol)
     : 신뢰성, 메세지 순서 보장
     : 연결성(발신자 수신자간 handshaking)
     : point-to-point
     : full duplex (전이중 방식), 하나의 Connection에서 양쪽으로 데이터 흐름
     : 혼잡 제어, pipelined(window size로 혼잡 및 흐름 제어)
     : send & receive buffers
     : HTTP, FTP, SMTP, Telnet 등에 사용


                        TCP segment structure



    ■ 3-hand-shaking 



    ■ 4-hand-shaking



    - UDP(User Datagram Protocol)
     : 비신뢰성, 메세지 비순서
     : 비연결성(발신자와 수신자간의 handshaking 없이 port만으로 소켓 구별, no-frills extension of “best-effort” IP)
     : 설계방식에 따라 full duplex, half duplex (반이중 방식)
     : reliability를 application layer상에 추가(RUDP)할 수 있지만 app-specific error만 복구 가능
     : RTT가 너무 짧으면 불필요한 재전송 발생, RTT가 너무 길면 느린 reaction과 segment 손실 가능성
     : RIP(Routing Information Protocol), DNS, NFS(Network File System), SNMP(Simple Network Management Protocol)등에 사용

     
                        UDP segment structure

      ■ Checksum
        : segment의 에러 체크
        : header + data + pseudo-header의 sum의 16 bit-one's complement 값
        : 모든 Data값과 checksum값을 더했을 때 모든 bit가 1로 채워져있다면 에러가 없음을 의미, 에러가 검출되면 해당 segment는 버려짐
       


     

  • Multiplexing and Demultiplexing


    Demultiplexing
      : host는 IP datagrams을 받음(IP와 PORT로 적합한 소켓을 구별)
       : 각 datagram은 source IP address, destination IP address를 가짐
       : 각 datagram은 1 transport-layer segment를 가짐
       : 각 segment는 source, destination port를 가짐



     1. Connectionless demultiplexing
      

    2. Connection-oriented demultiplexing
      


  • Principles of Reliable data transfer(RDT)
      
       

    : FSM(F
    inite State Machine)? 각각 loop를 돌고 있는 상태
    : ACKs(ACKnowledgements)? 수신자가 패킷을 받았다고 발신자에게 보내는 신호
    : NAKs(Negative ACKnowledgements)? 수신자가 패킷에 에러가 있다고 발신자에게 보내는 신호(seq# ack로 대체)
    : rdt 1.0? 수신, 발신 FSM을 분리 -> rdt 2.0? 에러 복구에 대한 ACK, NAK 도입 -> ACK/NAK 에러 발생시 발신자는 알수없으므로 중복 전송 가능성 -> rdt 2.1? 발신자는 ACK/NAK를 받았을 경우에만 재전송, 각 패킷에 sequence number를 붙임, 수신자는 중복 패킷 버림 (stop and wait) -> ACK/NAK에서 에러가 발생할 경우 전송한 패킷을 재전송 가능성 -> rdt 2.2? NAK 대신 마지막으로 받은 패킷의 seq를 ACK에 붙여 전송 -> 패킷이나 ACK에서 에러나 손실이 발생하면 무한정 기다리게 됨 -> rdt 3.0? time-out 도입

    1. Forward Error Correction(FEC)
      : Realtime communication
      : 수신자로 하여금 에러를 수정할 수 있도록 redundant bits를 추가 
    2. Retransmission
      : 수신자가 에러를 감지하고 발신자에게 data를 다시 전송해달라고 요청
     : ARQ(Automatic Repeat reQuest)
       : 수신자 피드백 방식, 오류검출만으로도 통신회선의 신뢰성 제고, 실시간 처리에는 부적합한 에러 제어 방법
       : 오류 검출, 수신 여부 피드백, 재전송 기능 등이 필요

       ■ Stop and Wait
         : 한 번에 하나씩 긍정 확인응답(ACK)을 받고, 후속 데이터 전송
         
    가장 단순하나, 다소 비효율적
         : 반이중 방식에서도 가능(Pipelining를 이용하여 효율 증가)

        

       ■ Go back N(GBN or Continuous ARQ)     
         
    Pipelining Protocol
         : 반이중 방식
         : Sliding Window 방식
         : 한번에 여러 개를 보낸후 하나의 긍정 확인응답(ACK)을 받고, 후속 데이터 전송.
         : 발신자는 패킷 n에 대해 timeout 발생시 패킷 n과 window 안에 있는 seq #이 n보다 높은 모든 패킷을 재전송
         : 수신자가 예기치 않은 패킷을 받을 경우, 그 패킷을 버리고 가장 최근에 받은 패킷의 ACK를 재전송

        

        

       ■ Selective Repeat
         Pipelining Protocol
         : 전이중 방식
         : Go back N 과 비슷하지만 오류가 발생된 패킷 이후 또는 오류 발생된 패킷만을 재전송
         : 수신자는 순서가 다르더라도 Receiver Window 안에 포함되는 패킷이라면 받을수 있으며 Buffer 해놓음.

        
        




'Major > Network' 카테고리의 다른 글

네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
네트워크 - Application Layer  (0) 2015.12.02
네트워크 - 기본  (0) 2015.12.01
Big-endian vs Little-endian  (0) 2015.11.16
  • Network Application



  • Application architectures

    - Client-Server
     

    - Peer-to-Peer (P2P)
     

    - Hybrid of client-server and p2p
     

  • Processes communicating
    : 같은 호스트간의 프로세스간 통신은 IPC(Inter-process communication)
    : 다른 호스트간의 통신은 Server process, Client process 로 이루어짐

    - Sockets
     : 발신자/수신자에게 메세지를 송수신하는 프로세스
     : 일종의 "door" 역할
     

    - Addressing processes
     : 수신 메세지를 받기위해 프로세스는 반드시 identifier를 가져야한다.
     : host는 유일한 32-bit(IPv4) IP address를 가진다.
     : identifier = IP address + PORT numbers

  • Application protocol defines
    : Types of messages exchanged (request, response)
    : syntax, semantics
    프로세스들이 언제, 어떻게 메세지를 주고 받는지에 대한 규칙

  • Web and HTTP
    : Web page 는 HTML file, JPEG image, Java applet, audio file 등의 객체들로 구성, HTML-file이 베이스
    : 각 객체들은 자체 주소(URL)을 가지고 있음



    - HTTP
     : HyperText Transfer Protocol
     : 웹 어플리케이션 레이어 프로토콜
     : client/server model
     : client? 브라우저가 requests, receives 한 웹 객체를 디스플레이 함
     : server? web server가 요청에 대한 응답으로 객체를 전송
     : http는 stateless protocol -> 서버는 클라이언트의 과거 요청을 유지하지 않음
     : RTT? RoundTripTime으로 클라이언트 요청이 서버로 응답이 오는 시간

      

       TCP 사용
        1. 클라이언트는 TCP Connection을 초기화 함(소켓을 만듦), PORT 80
        2. 서버는 클라이언트로부터 TCP Connection을 받음
        3. 브라우저(HTTP clinet)와 웹서버(HTTP server)간 HTTP messages를 주고 받음
        4. TCP Connection 종료

       Nonpersistent HTTP
        : 하나의 객체만 TCP를 통해 전송
        : HTTP 1.0에서 사용
        : Response time? total = 2RTT + transmit time
        : 객체(파일, 이미지 등)마다 2RTT와 TCP 연결에 대한 오버헤드 발생
        

       Persistent HTTP
        : 다수의 객체를 TCP를 통해 전송
        : HTTP 1.1에서 default로 사용
        : 서버는 응답을 보낸 후에도 Connection을 열어둠
        : client는 참조 객체를 마주했을 때 요청을 보냄
        : 객체마다 1RTT의 오버헤드가 감소함

      


            :3RTT + 2transmit time                      :2RTT + 1transmit time


    - HTTP request message

        
      ■ Header (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)

    분 류

    Massages

    Header

    설    명

    지 원 버 전

    생략여부

    HTTP1.0

    HTTP1.1

    Request

    Requst-Line

    Method※5

    GET,POST,HEAD

     

    OPTIONS,PUT,DELETE,TRACE

    ×

     

     

     

    Request-URI

    요청 데이터의 절대 주소나 상대주소.

    ex)http://www.isoft.co.kt/index.html or /test/helloworld.html

     

     

     

    HTTP-Version

    HTTP" + 0.9∼1.1(해당 프로토콜)

     

     

    Request-Header

    Authorization

    사용자 인증정보 - 사용자 ID와 암호가 함께 Base64로 인코딩※6

    ex)Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

     

     

     

    From

    자원의 생성자나 웹마스터의 전자우편 주소

    ex)From: psycho@isoft.co.kr

     

     

     

    If-Modified-Since

    GET 사용시-헤더 필드에 지정된 날짜보다 나중 자원만 전달(케시일자검색)

    ex)If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT

     

     

     

    Refer

    한페이지에서 다른페이지를 요청할 때 (링크시) 이전 페이지 주소제공

    ex)Referer: http://www.w3.org/hypertext/DataSources/Overview.html

     

     

     

    User Agenter

    browser 정보

    ex)User-Agent: MyWebBroswer/0.5

     

     

     

    Accept

    클라이언트의 사용가능 미디어타입

    ex)Accept: text/*, text/html, text/html;level=1, */*

    ×

     

     

    (Content

     Neogotation)

    Accept-Charset

    클라이언트에서 사용할 수 있는 문자 집합(생략시 모두인식)

    ex)Accepr: iso-8859-1, unicode-1-1

    ×

     

     

    (Content

     Neogotation)

    Accept-Encoding

    클라이언트에서 제공되는 인코딩 방법(압축)

    ex)Accept-Encoding: compress, gzip

    ×

     

     

     

    Accept-Language

    클라이언트가 인식할 수 있는 언어(우선순위가능)

    ex)Accept-Language: da, en-gb;q=0.8, en;q=0.7(독일어, 영국영어, 영어)

    ×

     

     

     

    Host

    서버의 기본URL(하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원)

    ex)www.w3.org

    ×

    ×

     

     

    If-Match

    ETag값 비교-Method수행-(PUT 메소드:해당header무시),다르면 402에러발생

    ex)If-Match: "0-556-343b9e36"

    ×

     

     

     

    If-None-Match

    ETag값 비교, 다를때-Method수행-(If-Match와 반대),같을 때 에러

    ex)If-None-Match: "0-556-343b9e36","0-1e4-34367116"

    ×

     

     

     

    If-Range

    클라이언트 캐시 정보를 업데이트 정보 (ETag or Date 비교)

    ×

     

     

     

    If-Unmodified-Since

    헤더값에 지정된 날자로부터 수정이 없는경우 Method를 수행

    ex) If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

    ×

     

     

     

    Max-Forwards

    이 메시지가 거쳐 갈수 있는 최대 Proxy의 개수를 지정

    ex)Max-Forwards: 7

    ×

     

     

     

    Proxy-Authorization

    비공개 프록시 서버 유저인증을 위한 코드

    ×

     

     

     

    Range

    자원의 일부분만 받을때(이어받기기능) 받을범위 지정

    ex)bytes=0-499            : <- 0~499byte를 얻고자 할 때.

    ×

     

      ■ Method

       

      ■ GET vs. POST
       : GET? URL 필드를 이용하여 업로드
       : POST? entity body를 이용하여 업로드
       : GET은 해당 요청을 몇번을 수행해도 해당 요청에 대한 결과가 계속 동일하게 돌아오는 것을 의미하며, POST는 해당 요청이 수행되면 서버에서 무언가 바뀌고, 동일한 결과가 돌아오는 것을 보장할 수 없다는 것을 의미한다.
       : POST의 경우 GET과는 달리 쿼리스트링(query string)의 글자 수 제약이 없으며, 파일업로드 등의 동작이 가능하다. 
    그리고 POST의 경우 쿼리스트링이 URL에 포함되지 않기때문에 user에게 파라메터 값 등을 덜 노출한 상태로 요청이 가능하다. 하지만 결국 HTTP 요청은 SSL을 이용하는 https가 아닌경우 plain text로 이루어게되고, 그러다보니 요청을 열어보면 쿼리스트링이 동일하게 보이는것은 마찬가지라 특별히 보안상 더 뛰어나다고는 말하기 힘들다.

    GET 요청은 브라우저에서 캐시를 할 수 있다.

    글을 작성하는 요청인데 GET 방식으로 글내용과 제목을 받아서 서버로 전송한다면, 해당 GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬가 되었다가 다시 사용될 우려가 있다. 이 경우 캐쉬에의해 자동으로 동일한 글을 또 작성하는 동작이 서버에서 발생될 수 있는데 이것은 심각한 오류이다.

    검색봇(크롤러)으로 인한 문제 발생

    구글이나 네이버의 검색봇(bot 혹은 crawler)들이 웹페이지 수집을 위해 해당 웹서버에 GET 요청을 할 수 있다. 이때 이러한 봇의 요청에 의해 게시판에 엉뚱한 데이터로 글이 작성되어 올라간다던지, 서버쪽의 데이터가 바뀐다면 당황스러운 일들이 발생할 가능성이 크다. 

    출처: http://www.letmecompile.com/get-post-%EB%B0%A9%EC%8B%9D-%EC%B0%A8%EC%9D%B4%EC%A0%90/


    - HTTP response

        

      ■ Header (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)

    분 류

    Massages

    Header

    설    명

    지 원 버 전

    생략여부

    HTTP1.0

    HTTP1.1

    Response

    Status-Line

    HTTP-Version

    HTTP" + 0.9∼1.1(해당 프로토콜)

     

     

     

    Status-Code

    수신상태코드-(4Page의 표참조.)

     

     

     

    Respon-Phrase

    수신 상태코드에 대한 간략한 설명-(4Page의 표참조.)

     

     

    Response-Header

    Location

    요구한 정보 실제 위치. 옮겨지거나 다를경우-정보주소가 실제 위치 정보.

    (redirection,forwording 단, 절대주소만 가능.)

     

     

     

    Server

    서버 프로그램의 이름과 버전 정보

    ex)Server: Apache/1.3a1

    ×

     

     

     

    WWW-Authenticate   

    사용자 인증이 필요한 자원을 요구시, 필요데이터와 서버가 제공하는 인증 방식

    ex)WWW-Authenticate: Basic realm="아이 소프트"

    ×

     

     

     

    Age

    요구후 원 서버(origin Server)에서 응답생성하지까지의 시간(초단위)

    ×

     

     

     

    Proxy-Authenticate

    서버가 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더이다.

    ×

     

     

     

    Public

    서버에서 지원 가능한 Method의 리스트(제한의 의미는없음)

    ex)Public: OPTIONS, MGET, MHEAD, GET, HEAD

    ×

     

     

     

    Retry-After

    503 에러시 -몇초(시간)후에 다시 요구 메시지를 보내라는 정보

    ex)Retry-After: Fri, 31 Dec 1999 23:59:59 GMT(Time)

       Retry-After: 120   (Second)

    ×

     

     

     

    Warning

    상태코드와 응답 구문에 추가적인 경고

    ×

     

      

    Vary

     

     ×

     


      ■ Status codes 
    (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)

    1xx: Informational -

     요구메시지를 받은 후

     연결 중 작업할 때.

    2xx: Success -

     요구메시지를 제대로 받았을 때.

    3xx: Redirection -

     요구메시지를 수행하기 위해

     다른 작업이 필요할 때.

    4xx: Client Error -

     요구 메시지의 형식이 틀리거나

     빠진 부분이 있을 때.

    5xx: Server Error -

    서버에 문제가 있을 때.

    100 Continue

    200 OK

     성공처리

    300 Multiple Choices

     (실제 발생하지 않음)

    400 Bad Request

     요구가 올바르지 않음

    500 Internal Server Error

     예기치 못한 서버처리오류

    101 Switching Protocols

    201 Created

     요구에따라 새로운자원생성(PUT)

    301 Moved Permanently

     URL이 확정적으로 옮겨짐

    401 Unauthorized

     사용자 인증이 필요

    501 Not Implemented

     요구에 대한 지원불가

     (transfer-Encoding)

     

    202 Accepted

     요구를 이해하였으며 진행중

    302 Moved Temporarily

     URL이 임시적으로 옮겨짐

    402 Payment Require

    502 Bad Gateway

     게이트웨이·프락시의 응답오류

     

    203 Non-Authoritative Information

    303 See Other

    403 Forbidden

     요구는 이해하나 수행거절(PUT)

    503 Service Unavailable

     서버부하로 응답불가

     

    204 No Content

     요구자료에 정보가 없음(empty)

    304 Not Modified(If-Modified-Since)

     수정날짜에 수정되지 않음

    404 Not Found

     요구한 파일이 없음

    504 Gateway Time-out

     

    205 Reser Content

    305 Use Proxy

    405 Method Not Allowed

     허락된 메소드가 아님

    505 HTTP Version not supported

     (요구를 무시할 수 있음..??)

     

    206 Partial Content

     

    406 Not Acceptable

     

     

     

     

    407 Proxy Authentication Required

     

     

     

     

    408 Request Time-out

     

     

     

     

    409 Conflict

     

     

     

     

    410 Gone

     

     

     

     

    411 Length Required

     

     

     

     

    412 Precondition Failed

     

     

     

     

    413 Request Entity Too Large

     

     

     

     

    414 Request-URI Too Large

     

     

     

     

    415 Unsupported Media Type

     


    - Cookies
     : server는 response를 보내고 나면 그 client는 잊어버린다. 웹사이트가 user를 구별하기 원하거나, user access를 제한하기를 원한다면?
     : cookies에는 그 user를 위한 identifier가 담겨있다.
     1. set-cookie header 를 HTTP response message에 포함
     2. cookie header는 request message에 포함
     3. cookie 파일은 user의 host에 계속 있고, user의 브라우저에 의해 관리된다.
     4. Back-end Database는 웹 사이트에 있다.
     : 세션유지에 사용

     Persistent Cookie: 브라우저를 종료해도 사용자의 하드드라이브에 저장. 만료시기가 되면 삭제
     Session Cookie: 웹 클라이언트(IE) CASH에 임시 저장. 삭제 시기는 서버에서 만료되면 삭제


      

    - Session
    : 사전적 의미로 "시간"을 의미
    : 클라이언트와 웹 서버간에 통신 연결에서 두 개체의 활성화된 접속을 뜻함
    : 클라이언트가 웹서버에 요청하여 처음 접속하면 JSP나 ASP 엔진은 요청한 클라이언트에 대하여 유일한 ID를 부여하게 되는데 이 ID를 세션이라 부름
    : 세션 ID를 임시로 저장하여 페이지 이동 시 이용하거나, 클라리언트가 재접속 했을 때 클라이언트를 구분할 수 있는 유일한 수단
    : 각각의 클라이언트마다 고유의 ID부여, 
    Session 객체들마다 저장해 둔 Data를 이용, 클라이언트 자신만의 고유한 페이지를 열어놓아서 생길 수 있는 보안상의 문제 해결 능력

    - Session vs. Cookie
     : Session은 서버 쪽에 정보를 저장하고, 쿠키는 클라이언트 쪽에 정보를 저장한다는 것이 가장 큰 차이점

    - Web caches(proxy server)
     : 클라이언트 요청에 대한 응답시간을 줄이고, 트래픽을 줄이기 위해 사용
     : cache 되지 않은 객체에 있어서는 낮은 성능, 또 cache 되어 있는 객체가 최신의 것이 아닐 수 도 있다. (해결 방안으로 
    If-Modified-Since)

      

  • FTP
    : File Transfer Protocol, RFC 959
    : 다른 host로부터 혹은 다른 host로 file을 전송할 때 사용하는 프로토콜
    : stateful protocol
    : client - server model
    transport protocol로 TCP 사용, FTP server는 PORT 21로 control connection(out-of-band), client는 PORT 20로 data connection
    : 암호화가 필요하여 최근에는 SFTP나 FTPS로 대체

      

  • Electronic Mail
    : 주요 3가지 컴포넌트로 user agents, mail servers, SMTP(Simple Mail Transfer Protocol)로 구성
    : user agents? mail reader, mail을 읽고, 편집
    : mail servers? mailbox + message queue + SMTP

     

    : SMTP? mail server 사이에서 메시지 전달을 위해 적용되는 프로토콜
    : transport protocol로 TCP 사용, PORT 25
    : persistent connection(여러 메시지를 하나의 TCP connection에서 전송 가능)
    : handshaking(greeting) -> transfer of message -> closure



    - HTTP vs. SMTP
     : HTTP 1.1과 SMTP 둘다 persistent connection
     : 둘다 ASCII 커맨드, status code를 가짐 
     : HTTP는 pull로 client가 요청으로 정보를 끌어옴, SMTP는 push로 요청하지 않아도 server가 mailbox까지 정보를 줌.
     : HTTP는 각 개체가 캡슐화, SMTP는 한 msg안에 여러 객체가 담긴다.

    - Mail access protocols
     : POP? Post Office Protocol, TCP 사용, download-and-keep, stateless across sessions
     : IMAP4? Internet Mail Access Protocol, 메세지 ID와 폴더 이름 간 매핑하여 user에게 접근 허가, user stateful across sessions
     : HTTP? gmail, naver 등
     

  • DNS
    : Domain Name System
    : IP 주소와 Name의 mapping가 필요함 -> name-address resolution
    : hostname을 ip주소로 변환, host aliasing, mail server aliasing, load distribution
    : UDP/TCP 둘 다 사용가능하지만 주로 UDP 사용, PORT 53
    : 트래픽, single point of failure, 거리, 확장성 등의 문제로 중앙 집권 구조로 구현하지 않고, 분산 데이터베이스로 많은 name server의 계층형태로 구현



    : www.amazon.com의 ip 주소를 얻는 과정
    1. client가 root server로 com DNS server를 찾기위해 query를 보낸다.
    2. client가 com DNS server로 amazon.com DNS server를 찾기위해 query를 보낸다.
    3. client가 amazon.com DNS server로 www.amazon.com의 ip 주소를 얻기 위해 query를 보낸다. -> 주소의 역순으로 접근하면서 ip주소를 찾아감
    : Root DNS server : 13개 (A~M) 세계적으로 존재
    : Top-level domain (TLD) servers? com, org, net, edu, etc, kr, uk, fr, ca, jp 등
    : Authoritative DNS servers? 어떤 단체에 대한 DNS 실제적인 IP주소
    : Local Name Server? 엄격한 계층구조가 아닌 각 ISP(default name server)를 하나씩 가지고 있음, host가 DNS query를 생성하면 query가 DNS server로 전송, 마치 프록시처럼 계층적으로 query 전달
    : caching and updating records

    - DNS name resolution

      
    :iterated query                                        :recursive query

  • P2P


    - BitTorrent
     : File은 256KB chunks로 쪼개짐
     : peer joining torrent: 시간이 흐름에 따라 chunk가 쌓인다. tracker로 등록하여 주번 peer list를 얻음
     : 다운로드 하는 동안 peer는 chunk를 다른 chunk부터 요청하여 받음, 가장 귀한 chunk부터 요청하여 받음)
     : Free Riding 방지 -> Tit-for-tat -> 많이 주는 쪽을 top-four providers로 선정 


    - Centralized index
     : peer들의 정보(ip, content)를 중앙서버에서 찾는 구조
     : single point of failure, 병목현상등의 문제 발생

     
    - DHT
     : Distributed Hash Table = Distributed P2P database 
     : DB는 (id, value) pairs 를 가짐, 각 peer 들은 query를 이용하여 (key, value) peers을 얻어낼 수 있음
     : Shortcuts(peer를 찾는 가장 짧은 경로), Peer Churn(Peer가 떠날 경우 successor를 새로 지정)
      


  • Summary

     


'Major > Network' 카테고리의 다른 글

네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
네트워크 - Application Layer  (0) 2015.12.02
네트워크 - 기본  (0) 2015.12.01
Big-endian vs Little-endian  (0) 2015.11.16
MAC address  (0) 2015.11.16
  • 인터넷이란?
    : "nuts and bolts"
    : QoS(Quality of Service)는 다른 응용 프로그램, 사용자, 데이터 흐름 등에 우선 순위를 정하여, 데이터 전송에 특정 수준의 성능을 보장하기 위한 능력

    - 네트워크 구성요소
      : hosts, communication links, routers
      

    - QOS : 최선 노력 서비스 (Best-Effort Service)
      : 현행 인터넷은 Dummy network이라하여 망측은 단순 멍청하고 단말측이 지능적인 역할을 하는 구조
        따라서, 망측에서는 IP데이타그램전송을 위하여 최대의 노력을 하지만, 확실한 전송의 보장을 하지는 않음.
        즉, 데이타의 흐름이 많거나 적거나 간에 시간지연이 없도록 하는 등의 신뢰성을 보증하지 않음
      : 이와 같이 양단간 사용자에게 네트워크측에서 보장은 못하지만 최선의 서비스 제공을 하려는 서비스 모델을 최선 노력 서비스 (Best-Effort Service) 모델이라고 함

    - 프로토콜
     
     :통신 프로토콜 또는 통신 규약 컴퓨터 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계이다. 통신 프로토콜은 신호 체계, 인증, 그리고 오류 감지 및 수정 기능을 포함할 수 있다. 프로토콜은 형식, 의미론, 그리고 통신의 동기 과정 등을 정의하기는 하지만 구현되는 방법과는 독립적이다. 따라서 프로토콜은 하드웨어 또는 소프트웨어 그리고 때로는 모두를 사용하여 구현되기도 한다.

  • Network edge
    : end systems, access networks, links


    - Access networks
      : Modem, DSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax, 동축케이블), FTTH(Fiber To The Home)
      : Modem은 같은 주파수 대역을 사용하기 때문에 전화와 인터넷 동시 사용 불가
      : DSL은 주파수의 높낮이에 따라 필터링하여 전화와 인터넷 동시 사용 가능
      : HFC는 30Mbps downstream, 2Mbps upstream로 라우터에 대역 공유
      : FTTH는 병목현상을 줄임

     Wireless access networks
     : wireless LANS: 802.11b/g/n (WiFi)


      : Home networks
     

    - Physical Media
    ■ guided media: 
     : signals propagate freely, e.g., radio
    ■ unguided media:
     : signals propagate in solid media: copper, fiber, coax

  • Network core
    : circuit switching, packet switching, network structure

    - Circuit switching
     : 공중교환전화망(public switched telephone network)에 사용
     : 네트워크 리소스(대역폭 등)를 "pieces"로 나누어 연결마다 할당
     : 유저가 적을 경우 고정된 대역폭으로 안정적임
     : 데이터가 전송 중이지 않을 때도 대역폭 할당, 많은 유저가 사용시 생기는 딜레이 등의 단점

     

    - P
    acket switching
     : 인터넷에 사용
     : 데이터 스트림을 패킷 단위로으로 나눔
     : Store-and-Forward 방식으로 라우터는 전송전에 완전한 패킷을 받음, Resource Sharing이 이루어짐, 각 패킷을 full link 대역폭 사용
     : 리소스가 필요할 때만 할당
     : 혼잡으로 인한 패킷 딜레이와 손실이 발생할 수 있으므로 신뢰성있는 프로토콜이 필요함

     

    ■ 
    패킷 딜레이의 4가지 요소


     

    1. processing
     : bit 에러 체크
     : 출력 링크 결정


    2. queueing
     : 출력 링크에 전송을 위한 대기 시간
     : 라우터의 혼잡 규모에 의존

    3. tranmission delay

     : L / R
     : L = packet length(bits)
     : R = link bandwidth(bps)

    4. propagation delay
     : d / s
     : d = length of physical link
     : s = propagation speed in medium (~2x10^8 m/sec)


      ■ 
      패킷 손실
       : 큐가 가득 차있는 경우 해당 패킷이 이전 노드에 의해 재전송 되거나 버려진다.
       

      처리량
       : 수신자, 발신자의 bits/ time unit 따라 달라짐
        


      - Network structure
       : ISP? Internet Service Provider

       


    • Protocal Layers
      : 네트워크들은 매우 복잡함
      : 각 계층별로 서비스를 구현한다면?
      : 복잡한 시스템을 모듈화하여 유지 보수 및 변화에 용이


       



       
       - Protocol Interfaces

         : 각 프로토콜은 2가지 인터페이스가 있다.
          1. service interface: operations on this protocol
          2. peer-to-peer interface: messages exchanged with peer
         : Layer n is the "service provider" for Layer n+1
         : n-PDU = Header(PCI) + n-SDU
         : n-PDU = (n-1)-SDU

       
          SDU: Service Data Unit

          SAP: Service Access Point
          PCI: Protocol Control Information
          PDU: Protocol Data Unit


       - Encapsulation & De

      capsulation


       





    • 네트워크 보안
      - Trojan horse

       : 유용한 소프트웨어에 숨어 있는 것 

      - Virus
       
      : e-mail 등으로 능동적으로 실행
       : 자가증식하면서 다른 호스트들도 감염시킴 

      - Worm

       : 수동적으로 실행하게 함
       : 자가증식하면서 다른 호스트들도 감염시킴 

      - DoS(Denial of Service), DDoS(Distributed Denial of Service)
       
      - Packet sniffing

        

      - IP spoofing
        


      - Man-in-the-middle attack

       





    'Major > Network' 카테고리의 다른 글

    네트워크 - Transport Layer  (0) 2015.12.09
    네트워크 - Application Layer  (0) 2015.12.02
    네트워크 - 기본  (0) 2015.12.01
    Big-endian vs Little-endian  (0) 2015.11.16
    MAC address  (0) 2015.11.16
    OSI 7 계층  (0) 2015.11.15

    엔디언(Endianness)은 컴퓨터의 메모리와 같은 1차원의 공간에 여러 개의 연속된 대상을 배열하는 방법을 뜻하며, 바이트를 배열하는 방법을 특히 바이트 순서(Byte order)라 한다.


    엔디언은 보통 큰 단위가 앞에 나오는 
    빅 엔디언(Big-endian)과 작은 단위가 앞에 나오는 리틀 엔디언(Little-endian)으로 나눌 수 있으며, 두 경우에 속하지 않거나 둘을 모두 지원하는 것을 미들 엔디언(Middle-endian)이라 부르기도 한다.


    Big-Endian Little-Endian


    바이트 순서

    바이트 순서는 크게 빅 엔디언과 리틀 엔디언으로 나눌 수 있다. 빅 엔디언은 사람이 숫자를 쓰는 방법과 같이 큰 단위의 바이트가 앞에 오는 방법이고, 리틀 엔디언은 반대로 작은 단위의 바이트가 앞에 오는 방법이다.PDP-11과 같은 몇몇 아키텍처는 2바이트 단위와 1바이트 단위로 서로 다른 순서를 사용하기도 하는데 이들을 미들 엔디언이라 부른다. 다음은 이런 방법들을 비교한 것이다.

    종류0x1234의 표현0x12345678의 표현
    빅 엔디언12 3412 34 56 78
    리틀 엔디언34 1278 56 34 12
    미들 엔디언-34 12 78 56
    또는
    56 78 12 34

    두 방법 중 어느 한 쪽이 다른 쪽과 비교해 압도적으로 좋거나 나쁘지는 않다고 알려져 있으며, 두 방법은 서로 다른 여러 아키텍처에서 서로 공존하고 있다. 그러나 x86 아키텍처가 리틀 엔디언을 쓰기 때문에, 오늘날 x86 아키텍처를 사용하는 대부분의 데스크톱 컴퓨터는 리틀 엔디언을 쓰며 이를 ‘인텔 포맷’이라 한다. 거꾸로 네트워크에서는 주소를 빅 엔디언으로 쓰는데, 역사적으로 라우팅이 전화를 거는 식으로 접두 부호로 이루어졌기 때문이다. 이의 영향으로 많은 프로토콜과 몇몇 파일 포맷이 빅 엔디언을 사용하고 있다. 모토로라 프로세서들은 일반적으로 빅 엔디언을 사용하며, ARM 프로세서들은 성능 향상을 위해 빅 엔디언과 리틀 엔디언을 선택할 수 있도록 되어 있다.

    장단점

    빅 엔디언은 소프트웨어의 디버그를 편하게 해 주는 경향이 있다. 사람이 숫자를 읽고 쓰는 방법과 같기 때문에 디버깅 과정에서 메모리의 값을 보기 편한데, 예를 들어 0x59654148은 빅 엔디언으로 59 65 41 48로 표현된다.

    반대로 리틀 엔디언은 메모리에 저장된 값의 하위 바이트들만 사용할 때 별도의 계산이 필요 없다는 장점이 있다. 예를 들어, 32비트 숫자인 0x2A는 리틀 엔디언으로 표현하면 2A 00 00 00이 되는데, 이 표현에서 앞의 두 바이트 또는 한 바이트만 떼어 내면 하위 16비트 또는 8비트를 바로 얻을 수 있다. 반면 32비트 빅 엔디언 환경에서는 하위 16비트나 8비트 값을 얻기 위해서는 변수 주소에 2바이트 또는 3바이트를 더해야 한다. 보통 변수의 첫 바이트를 그 변수의 주소로 삼기 때문에 이런 성질은 종종 프로그래밍을 편하게 하는 반면, 리틀 엔디언 환경의 프로그래머가 빅 엔디언 환경에서 종종 실수를 일으키는 한 이유이기도 하다.

    또한 가산기가 덧셈을 하는 과정은 LSB로부터 시작하여 자리 올림을 계산해야 하므로, 첫 번째 바이트가 LSB인 리틀 엔디언에서는 가산기 설계가 조금 더 단순해진다. 빅 엔디언에서는 가산기가 덧셈을 할때 마지막 바이트로부터 시작하여 첫 번째 바이트까지 역방향으로 진행해야 한다. 그러나 오늘날의 프로세서는 여러개의 바이트를 동시에 읽어들여 동시에 덧셈을 수행하는 구조를 갖고 있어 두 엔디언 사이에 사실상 차이가 없다.

    바이 엔디언

    몇몇 아키텍처는 빅 엔디언과 리틀 엔디언 중 하나를 선택할 수 있도록 설계되어 있고, 이를 바이 엔디언(Bi-endian)이라 부른다. ARMPowerPCDEC 알파MIPSPA-RISCIA-64 등은 바이 엔디언을 사용하는 대표적인 아키텍처이다. 이들 대부분은 컴퓨터가 시작된 상태에서 소프트웨어적으로 바이트 순서를 바꿀 수 있지만, 몇몇은 하드웨어에 내장된 펌웨어에서 바이트 순서를 선택해야 하는 경우도 있다.

    미들 엔디언

    종종 한 방향으로 순서가 정해져 있는 게 아니라, 이를테면 32비트 정수가 2바이트 단위로는 빅 엔디언이고 그 안에서 1바이트 단위로는 리틀 엔디언인 경우가 종종 있는데 이를 미들 엔디언(Middle-endian)이라 한다.VAX와 ARM에서는 배정도 부동 소수점 실수를 미들 엔디언으로 저장하며, PDP-11에서는 32비트 정수를 미들 엔디언으로 저장하는데 이를 PDP 엔디언이라 부르기도 한다.

    비트 순서

    보통 바이트나 옥텟은 원자적인 단위로 간주되지만 종종 비트 단위의 접근이 필요할 수 있다. 따라서 바이트 순서가 아니라 비트 순서를 따질 수도 있으나, 여러 가지 이유로 비트 순서는 상대적으로 덜 중요하다. 보통 메모리의 접근은 바이트 단위로 이루어지기 때문에 비트 단위의 접근에는 별도의 연산 과정이 필요한데, 이러한 연산 자체가 비트 순서에 대해 잘 정의되어 있기 때문에 비트를 접근하는 방법은 아키텍처에 중립적이다.

    비트 순서와 비슷하게, 네트워크 프로토콜이나 파일 포맷 같이 저수준으로 내려 갈 경우 비트 단위의 데이터를 최상위 비트부터 채울 것인가 최하위 비트부터 채울 것인가 하는 문제가 있다. 예를 들어 C는 구조체에서 바이트보다 더 작은 단위의 변수를 선언할 수 있는 비트 필드를 지원하는데, 여러 개의 비트 필드가 배열되는 방법은 기계어를 생성하는 과정에서 중요해진다. 이때 최상위 비트(MSB)부터 채우는 것을 최상위 비트 우선, 최하위 비트(LSB)부터 채우는 것을 최하위 비트 우선이라 한다. 예를 들어 PNG와 GIF는 각각 최상위/최하위 비트 우선을 쓰는 대표적인 파일 포맷이다.

    출처: 위키, http://genesis8.tistory.com/37
        

    'Major > Network' 카테고리의 다른 글

    네트워크 - Transport Layer  (0) 2015.12.09
    네트워크 - Application Layer  (0) 2015.12.02
    네트워크 - 기본  (0) 2015.12.01
    Big-endian vs Little-endian  (0) 2015.11.16
    MAC address  (0) 2015.11.16
    OSI 7 계층  (0) 2015.11.15

    MAC 주소

    컴퓨터 네트워킹에서 매체 접근 제어 주소(MAC 주소), 이더넷 하드웨어 주소어댑터 주소는 대부분의 네트워크 어댑터(NIC)에 부착된 준고유 식별자이다. 특정한 네트워크 어댑터의 이름같이 동작하는 숫자이다. 그러므로 이를테면, 두 개의 서로 다른 컴퓨터에 있는 랜카드는 서로 다른 이름, 곧 서로 다른 MAC 주소를 가지고 있다. 라우터 안에 있는 여러 개의 랜카드, 같은 컴퓨터 안에 있는 이더넷 어댑터와 무선 어댑터도 이와 마찬가지로 적용된다. 그러나 오늘날 출시되는 대부분의 하드웨어에서는 MAC 스푸핑(MAC spoofing)을 통해 맥 주소를 바꿀 수 있다.

    MAC은 총 48비트로 구성되어 있으며, 이 가운데 첫 24비트는 OUI(Organizational Unique Identifier) 제조업체의 식별코드 , NIC 제조업체의 정보 24비트를 뺀 나머지 24비트는 랜 카드의 정보를 담고 있다.

    다음의 기술들이 MAC-48 식별자 형식을 사용한다:

    EUI-64 식별자는 다음에 쓰인다:


    컴퓨터가 네트워크상에서 서로를 구분하기 위해서는 각각의 일종의 주소가 필요하다. 편지를 서로 주고 받기 위해서는 각각의 건물이나 집에서 서로 다른 주소가 필요한 것처럼 컴퓨터 네트워크 상에서 이 역할을 담당하는 것이 바로 맥(Media Access Control) 주소이다.
    물론 인터넷은 TCP/IP로 통신을 하며 이떄 IP주소를 사용하지만 이 IP주소를 다시 MAC으로 바꾸는 과정을 거친다. 이 과정을 ARP(Address Resolution Protocol)라고 한다.

    출처: 위키


    'Major > Network' 카테고리의 다른 글

    네트워크 - Transport Layer  (0) 2015.12.09
    네트워크 - Application Layer  (0) 2015.12.02
    네트워크 - 기본  (0) 2015.12.01
    Big-endian vs Little-endian  (0) 2015.11.16
    MAC address  (0) 2015.11.16
    OSI 7 계층  (0) 2015.11.15

    + Recent posts