[Section 2] 네트워크 (웹 애플리케이션 작동 원리)

dohyoungK·2023년 5월 31일
0

네트워크 (웹 애플리케이션 작동 원리)

  • 네트워크를 만드는 기술

    • LAN과 WAN

      : 좁은 범위에서 연결된 네트워크를 LAN(Local Area Network)라 부른다. 그리고 수많은 LAN들이 모여 세계의 네트워크를 구성하는 WAN(Wide Area Network)가 된다.

    • 인터네트워킹(internetworking)

      : 여러 네트워크를 연결하는 것으로 전 세계적으로 인터네트워킹 하는 것이 우리가 사용하는 인터넷이다.

      • 장점

      1. 네트워크의 일부에서 고장이 나도 영향이 광범위하게 퍼지지 않는다.
      2. 불필요한 통신이 네트워크 전체로 퍼지지 않는다.
      3. 개별 네트워크를 각각의 방침에 따라 관리 가능하다.
    • 프로토콜(protocol)

      : 어느 컴퓨터든 일관되게 네트워크를 사용할 수 있도록 정의한 규칙 체계

    • TCP/IP

      : 인터넷 통신 스위트(Internet Protocol Suite)는 인터넷에서 컴퓨터들이 서로 정보를 주고받는데 쓰이는 통신규약의 모음이다. 이 중 현재까지 표준으로 사용하고 있는 TCP(Transmission Control Protocol)와 IP(Internet Protocol)에서 가져와 TCP/IP라 부른다.

    • TCP/IP 4계층 모델

      TCP/IP 4계층 모델주요 프로토콜역할
      응용 계층HTTP, DNS, FTP애플리케이션에 맞춰 통신한다.
      전송 계층TCP, UDPIP와 애플리케이션을 중개해 데이터를 확실하게 전달한다.
      인터넷 계층IP, ICMP, ARP, RARP네트워크 주소를 기반으로 데이터를 전송한다.
      네트워크 접근 계층Ethernet, wifi컴퓨터를 물리적으로 네트워크에 연결해서 기기 간 전송이 가능하게 한다.
    • IP 주소(IP address: Internet Protocol address)

      : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계

    • IP 주소 구조

      서브넷 마스크(subnet mask)
      : IP 주소에서 네트워크부가 어디까지인지 나타내는 것

      • IPv4 주소의 형태 => XXX.XXX.XXX.XXX (마침표로 구분된 4개의 8비트 필드)
      • IP 주소는 네트워크부와 호스트부로 나뉜다.
        네트워크부: 어떤 네트워크인지에 대한 정보
        호스트부: 그 네트워크 안의 특정 컴퓨터를 지칭하는 정보
    • MAC 주소

      : 이더넷에서 네트워크 상의 송수신 상대를 특정하고자 사용하는 주소이다. 그리고 같은 LAN에 속한 기기끼리 통신할 때 상대의 MAC 주소를 파악하기 위해 ARP(Address Resolution Protocol)를 사용하며, ARP는 네트워크 전체에 브로드캐스트로 패킷을 보내고 해당 IP를 가진 컴퓨터가 자신의 MAC 주소를 응답하면서 통신이 가능하게 해주는 프로토콜이다.

    • 통신

    1. 회선 교환 방식(Circuit Switching): 통신 회선을 통해 일대일로 데이터 교환
    2. 패킷 교환 방식(Packet Switching): 원본 데이터를 패킷이라는 작은 단위로 나눠 여러 회선을 공용해 통신하며 패킷은 헤더와 페이로드로 구성되어 있고, 헤더는 어떤 데이터의 몇 번째 데이터인지의 정보와 보내는 곳, 최종 목적지 등이 들어있다.
    • TCP와 UDP

      : TCP와 UDP는 TCP/IP 4계층 모델에서 IP 프로토콜의 계층인 인터넷 계층의 상위에서 동작한다. 그리고 전송 계층에 속하는 TCP와 UDP는 인터넷 계층에서 동작하는 IP와 응용 계층에서 동작하는 애플리케이션을 중개하는 역할을 한다.

      TCP(Transmission Control Protocol)UDP(User Datagram Protocol)
      서비스 타입연결 지향 프로토콜데이터그램 지향 프로토콜
      신뢰성데이터 전송 표적 기기까지의 전송을 보장O표적 기기까지의 전송을 보장X
      순서 보장전송 패킷들의 순서가 보장O패킷 순서 보장X
      속도UDP와 비교해 느림TCP와 비교해 빠르고, 단순하며 효율적
      • 데이터의 신뢰성을 필요로 하는 애플리케이션은 TCP, 빠른 속도나 실시간 통신이 중요한 애플리케이션은 UDP 사용.
    • TCP 3way handshake

      : 양 끝단 기기의 신뢰성 있는 데이터 통신을 위해, TCP 방식이 연결을 설정하는 방법

    1. sender는 receiver와 연결을 위해, segment를 랜덤으로 설정된 SYN(Synchronize Sequence Number)와 함께 보낸다.
    2. receiver는 받은 요청을 바탕으로 SYN/ACK 신호 세트를 응답한다. ACK(Acknowlogement) 응답으로 보내는 segment가 유효한 SYN 요청을 받았는지 의미한다.
    3. sender는 받은 ACK를 receiver에게 전송하면서 신뢰성 있는 연결이 성립되었다는 사실을 알리고 데이터 전송이 시작된다.
    • PORT

      : 포트 번호는 대상 IP기기의 특정 애플리케이션을 특정하는 번호로 0 ~ 65535번까지 사용할 수 있다.

      포트 번호 범위설명
      Well known port0 ~ 1023시스템 사용 번호(슈퍼유저 권한 필요 O)
      Registered port1024 ~ 49151특정 프로토콜이나 애플리케이션에서 사용하는 번호(슈퍼 유저 권한 필요 X)
      Dynamic port49152 ~ 65535애플리케이션, 혹은 임시 사용 번호
    • 자주 사용되는 포트 번호

      포트 번호프로토콜 이름전송 프로토콜설명
      80HTTPTCP웹서버 접속
      443HTTPSTCP웹서버 접속(SSL)
      110POP3TCP메일 읽기
      25SMTPTCP메일서버간 메일 전송
      22SSHTCP컴퓨터 원격 로그인
      53DNSUDPDNS 질의
      123NTPTCP시간 동기화
    • URL(Uniform Resource Locator)

      : 웹에 게시된 자원을 찾기 위한 브라우저에서 사용되는 메커니즘으로, 서버가 제공되는 환경에 존재하는 파일의 위치를 나타낸다.

    • URI(Uniform Resource Identifier)

      : URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함한다.

      부분명칭설명
      file://, http://, https://scheme통신 프로토콜
      127.0.0.1, www.google.comhosts웹 페이지나 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
      :80, :443, :3000port웹 서버에 접속하기 위한 통로
      /search, /User/username/Desktopurl-path웹 서버의 루트 디렉토리부터 웹 페이지, 이미지, 동영상 등의 파일의 위치까지의 경로
      q=Javaquery웹 서버에 전달하는 추가 질문
    • Domain name

      : 웹 사이트의 주소를 IP 주소로만 표현하면 기억하기 어렵기 때문에 호스트 이름과 도메인 이름으로 바꾸어 사용한다.

    • 도메인 종류

    1. gTLD (generic Top Level Domain): 전 세계적으로 등록 가능한 .com, .net, .org, .edu 등의 도메인
    2. ccTLD (country Top Level Domain): 각국에서 관리하는 .kr, .us, .jp 등의 도메인
    • DNS(Domain Name System)

      : 호스트의 도메인 이름을 IP 주소로 변환하거나 반대 경우를 수행하도록 개발된 데이터베이스 시스템
    • DNS 동작 과정(DNS Lookup)

    1. URL에 deploy.states.com 주소를 입력한다.
    2. 브라우저는 리졸버(요청받은 도메인의 IP 주소를 찾기 위해 여러 네임 서버에 반복적으로 질의하는 네임 서버)에게 IP 주소를 요청한다. 그리고 리졸버는 기존에 찾아본 도메인 정보가 담긴 캐시 파일을 살펴본 후, 있다면 즉시 IP 주소를 리턴한다.
    3. 정보가 없다면 네입 서버들에게 재귀적인 쿼리를 진행한다. 루트, 탑 레벨, 권한 있는 도메인 서버에 차례로 쿼리를 진행하며 IP 주소를 찾는다.
    4. 마지막으로 리졸버는 전달받은 deploy.states.com의 IP 주소를 기록하고 브라우저에 전달한다.
  • 웹을 구성하는 기술

    • 웹(WEB)

      : 인터넷에서 제공되는 하이퍼텍스트(문서 안에 다른 문서의 위치정보 등을 포함해 문서 간의 정보를 서로 연관지어 참조할 수 있는 문서) 시스템
    • 클라이언트-서버 아키텍처(2티어 아키텍처)

      : 웹에서 제공되는 서비스는 서비스를 이용하는 클라이언트와 서비스를 제공하는 서버로 나뉘고 이러한 구조를 클라이언트-서버 아키텍처라 한다. 그리고 2티어 아키텍처에 데이터베이스를 추가하면 3티어 아키텍처가 된다.
    • 웹 애플리케이션 아키텍처

      : 웹 애플리케이션 아키텍처는 클라이언트-서버 간의 연결에 대한 설명 방법으로, 애플리케이션 내부 요소들이 상호 간에 어떻게 소통하는지 설명한다.
    • 웹 애플리케이션의 요청흐름

    1. 브라우저에 https://urclass.codestates.com을 입력한다.
    2. 브라우저는 URL을 입력받으면 서버의 주소를 찾기 위해 DNS 서버에 요청을 보낸다.
    3. IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보낸다.
    4. 웹 서버에 요청이 도착한다.
    5. 웹 서버는 저장소에 요청을 보내 페이지 관련 데이터를 가져온다.
    6. 정보들은 가져오는 중에 비즈니스 로직이 작용한다.
    7. 비즈니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져있다.
    8. 로직들을 통해 요청받은 데이터들이 처리되고 브라우저에 응답하낟.
    9. 요청들이 브라우저에 응답으로 돌아왔을 때, 웹 페이지 화면에 출력된다.
    • 웹 애플리케이션의 3단계 계층 구조

    1. Presentation Layer: 유저와 브라우저 등을 이용해 직접적으로 접촉을 합니다. Web Server가 이 영역에 포함되며, 유저 인터페이스 요소들을 포함한다.
    2. Application Layer: Business Layer, Business Logic, Domain Logic 이라고도 불리는 이 영역은 유저의 요청을 받아서 처리하는 영역이다. Application Server가 이 계층에 포함되며, 데이터 접근을 위한 경로를 규격화하는 등의 과정이 이 계층에 작성된다.
    3. Data Access Layer: Persistence Layer 라고도 불리는 이 계층은 애플리케이션의 데이터 저장소에 접근하여 데이터를 불러오거나 저장을 담당한다.
    • 웹 애플리케이션 구현방식

    1. Single Page Application: 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어진다. 필수적인 요소만을 요청하고, 이러한 점은 페이지가 새로 고침 되는 것을 방지해 유저 경험을 극대화한다. 그리고 이러한 기능을 위해 AJAX, Asynchronous JavaScript, XML이 사용된다.
    2. Microservice Architecture: 작고 가벼운 특정한 한 가지 기능에 집중한 웹 애플리케이션을 의미한다.
    3. Serverless Architecture: 개발자가 웹 애플리케이션 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식이다.
    • : 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 한다. 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 동작하게 도와준다.

    • Session

      : 세션의 경우 서버에 Session-Id라는 고유 아이디를 할당해서 유저를 식별한다. 단순하고 유출되면 안되는 정보는 서버에서 관리하며 세션 ID와 매칭해서 저장해 관리한다. 주로 사용되는 방법은 세션 정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적이다.

    • SSR과 CSR

      SSR(Server Side Rendering): Javascript가 웹 페이지를 브라우저에서 렌더링하는 대신, 서버에서 렌더링한다. 브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송한 후, 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.

      CSR(Client Side Rendering): SSR이 서버 측에서 Javascript가 페이지를 렌더링한다면, CSR은 클라이언트에서 Javascript가 페이지를 렌더링한다.

      • SSR의 사용

      1. SEO(Search Engine Optimization) 검색 엔진 최적화가 우선순위인 경우, SSR을 사용한다.
      2. 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, SSR이 적합하다.
      3. 웹 페이지가 사용자와 상호작용이 적은 경우, SSR을 활용할 수 있다.
      • SSR의 단점

      1. 자원 이용이 서버에 집중되므로 애플리케이션 유지비용이 높다.
      2. 일부 서드파티 자바스크립트 라이브러리의 경우 SSR이 불가능할 수 있다.
      • CSR의 사용

      1. SEO가 우선순위가 아닌 경우, CSR을 사용한다.
      2. 사이트에 상호작용이 많은 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공한다.
      3. 웹 애플리케이션을 제작하는 경우, CSR을 이용해 빠른 동적 렌더링을 제공할 수 있다.
      • CSR의 단점

      1. 느린 렌더링 속도로 사용자 경험이 안 좋아질 수 있다. 모든 렌더링의 부하가 클라이언트 쪽에 집중된다.
    • CORS(Cross-Origin Resource Sharing)

      : 교차 출처 리소스 공유는 추가 HTTP 헤더를 사용해, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.

  • HTTP

    : HTTP(HyperText Transfer Protocol) 은 HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다. 그리고 HTTP는 특정 상태를 유지하지 않는 무상태성(클라이 언트와 서버가 통신을 주고받는 과정에서, HTTP는 클라이언트나 서버의 상태를 확인하지 않는다.)의 특징이 있다.

    • HTTP Messages

      : 클라이언트와 서버 사이에서 데이터가 교환되는 방식으로 요청(Requests)과 응답(Responses)의 두가지 유형이 있다.

      • 요청과 응답의 구조

      1. start line, status line: 요청이나 응답의 상태를 나타낸다.

      2. HTTP headers: 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합.

      3. empty line: 헤더와 본문을 구분하는 빈 줄

      4. body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다.

        이 중 start line과 HTTP headers를 헤드라고 하고, payload는 body라 한다.

      • 요청(Requests)

        Start Line
      1. 수행할 작업(GET, POST, PUT 등)이나 방식(HEAD, OPTIONS)을 설명하는 HTTP method를 나타낸다.

      2. 요청 대상(URL, URI 등) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다. 요청 형식(?와 쿼리 문자열이 붙는 origin 형식, 완전한 URL 형식인 absolute 형식, 도메인 이름과 포트 번호로 이루어진 URL의 authority component인 authority 형식, OPTIONS와 함께 *로 서버 전체를 표현하는 asterisk 형식)은 method마다 다르다.

        Headers

      3. 헤더 이름 : 값 의 형태의 구조이다.

      4. General headers: 메시지 전체에 적용되는 헤더

      5. Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

      6. Representation headers: body에 담긴 리소스 정보를 포함하는 헤더

        Body

      7. HTTP messages의 마지막에 위치하며, POST나 PUT처럼 데이터를 업데이트할 때 body가 필요하다.

      • 응답(Responses)

        Status Line
      1. 프로토콜의 버전, 상태 코드, 상태 텍스트의 구조. HTTP/1.1 404 Not Found.

        Headers

      2. 헤더 이름 : 값 의 형태의 구조이다.

      3. General headers: 메시지 전체에 적용되는 헤더

      4. Request headers: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더

      5. Representation headers: body에 담긴 리소스 정보를 포함하는 헤더

        Body

      6. HTTP messages의 마지막에 위치하며, 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다.

    • API

      : API(Application Programming Interface)는 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 제공하는 인터페이스다.

      요청적절한 메서드
      조회 (READ)GET
      추가 (CREATE)POST
      갱신 (UPDATE)PUT or PATCH
      삭제 (DELETE)DELETE

0개의 댓글