오늘 한 일
코딩 테스트 연습
- 부족한 금액 계산하기
- 문자열 다루기 기본
- 행렬의 덧셈
- 직사각형 별찍기
- process.stdin.on('data', (data) => {}) // stdio입출력 처리 메서드
node.js 배경지식 익히기
1. 웹과 HTTP의 동작 방식
- 웹브라우저: HTML, css, JavaScript 파일을 처리해 웹페이지로 보여주는 프로그램
- 주소를 입력하면 서버로부터 웹페이지 표시에 필요한 파일들을 받아 처리한다
- URL(Unirofm Resource Locator)
- 웹에서 고유 리소스의 주소
-
- URL은 스키마, 권한(도메인 이름, 포트), 리소스 경로, 매개변수, 앵커로 구성된다
- 스키마 : URL의 첫 번째 부분은 브라우저가 리소스를 요청하는 데 사용해야 하는 프로토콜을 나타낸다
- 권한 : 권한은 문자 패턴 ://에 의해 스키마와 구분된며, 콜론으로 구분된 도메인과 포트를 모두 포함한다
- 도메인은 요청하는 웹 서버를 나타낸다. 일반적으로 도메인 이름이지만 IP주소도 사용될 수 있다.
- 포트는 웹 서버의 리소스에 접근하는 데 사용되는 기술적인 "게이트"를 나타낸다. 웹 서버가 HTTP프로토콜의 표준 포트(http: 80, https: 443)를 사용하는 경우에는 일반적으로 생략한다.
- 리소스 경로 : 웹 서버에 있는 리소스의 경로. 웹 초기에는 이와 같은 경로가 웹 서버의 실제 파일 위치를 나타냈다. 요즘은 대부분 물리적 실체가 없는 웹 서버가 추상적으로 처리한다.
- 매개변수 : 웹 서버에 제공되는 추가 매개변수. 매개변수는 &기호로 구분된 키=쌍 목록이다. 웹 서버는 이러한 매개변수를 사용하여 추가 작업을 수행할 수 있다. 각 웹 서버에는 매개변수에 관한 고유한 규칙이 있으며 특정 웹 서버가 매개변수를 처리하는지 알 수 있는 신뢰할 수 있는 유일한 방법은 웹 서버 소유자에게 물어보는 것이다.
- 앵커 : 리소스 내부에서 일종의 "책갈피" 역할을 하며, 브라우저에 해당 "책갈피" 지점의 콘텐츠를 표시하도록 지시한다. 예를 들어 HTML문서에서는 브라우저가 앵커가 정의된 지점으로 스크롤한다. 비디오 또는 오디오 문서에서는 앵커가 나타내는 시간으로 이동하려 시도한다. 프래그먼트 식별자라고도 하는 # 뒤의 부분은 요청과 함께 서버로 전송되지 않는다.
- 어떤 URL이든 브라우저의 주소창에 입력하면 리소스에 액세스 할 수 있다.
- HTML에서 URL을 사용하는 방법
- <a> : 다른 문서에 대한 링크를 생성한다
- <link>, <script> : 문서와 관련 리소스를 연결한다
- <img>, <video>, <audio> : 미디어를 표시한다
- <iframe> : 다른 HTML문서를 표시한다
- 페이지의 일부로 로드할 리소스의 URL을 지정할 때는 몇 가지 예외가 있지만(data: 등)일반적으로 HTTP와 HTTPS만 사용해야 한다.
- 절대URL과 상대URL
- URL의 필수 부분은 URL이 사용되는 컨텍스트에 따라 크게 달라진다. 브라우저의 주소창에서 URL에는 아무 맥락도 없으므로 전체 URL을 입력해야한다. 프로토콜과 포트는 생략할 수 있지만 다른 부분은 모두 필요하다.
- URL이 HTML 페이지와 같은 문서 내에서 사용되는 경우, 브라우저에는 이미 문서 고유의 URL이 있기 때문에 이 정보를 사용하여 해당 문서에서 사용하는 URL의 누락된 부분을 채울 수 있다.
- 시맨틱 URL : URL은 결국 사람이 읽을 수 있는 웹 사이트 진입점을 나타내므로, 누구나 이해할 수 있는 고유의 의미를 가진 단어를 사용해야한다. 물론 언어 의미론은 컴퓨터와 관련이 없다. 하지만 사람이 읽을 수 있는 URL을 만들면 많은 이점이 있다.
- URL을 쉽게 조작할 수 있다.
- 사용자가 어디에 있는지, 무엇을 하고 있는지, 웹에서 무엇을 읽거나 상호작용 하는지에 대해 명확하게 설명한다.
- 일부 검색 엔진은 이러한 의미 체계를 사용하여 관련 페이지의 분류를 개선할 수 있다.
- 참고 : https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/What_is_a_URL
2. DNS
- 도메인 네임 시스템(Domain Name System, DNS)은 인터넷에 연결된 리소스에 대한 계층적이고 분산된 명명 시스템이다. DNS는 도메인 네임 목록과 도메인 네임에 연결된 IP주소 등의 리소스를 유지 및 관리한다.
- DNS의 가장 중요한 기능은 인간에게 친숙한 도메인 네임을 숫자 IP주소로 변환하는 것이다. 도메인 네임을 적절한 IP주소에 매핑하는 과정을 DNS조회라고 한다. 반대로, IP주소를 적절한 도메인 네임에 매핑하는 과정을 역방향 DNS조회(rDNS)라고 한다.
- 참고 : https://developer.mozilla.org/ko/docs/Glossary/DNS
3. IP(Internet Protocol)
- IP주소는 IP 네트워크의 각 장치를 고유하게 지정하는데 사용되는 번호이다.
- IP는 주소가 연결된 프로토콜 계층인 Internet Protocol을 의미한다.
- IPv4는 인터넷 기반 통신 프로토콜의 네 번째 버전이며, 널리 보급된 첫 번째 버전이다.
- IPv4는 패킷 교환 네트워크 상에서 데이터를 교환하기 위한 프로토콜이다. 데이터가 정확하게 전달될 것을 보장하지 않고, 중복된 패킷을 전달하거나 패킷의 순서를 잘못 전달할 가능성도 있다.(데이터의 정확하고 순차적인 전달은 그보다 상위 프로토콜인 TCP에서 보장한다.)
- IPv4의 주소체계는 총 12자리이며, 네 부분으로 나뉜다. 각 부분은 0~255까지 3자리의 수로 표현된다. IPv4 주소는 32비트로 구성되며, 현재는 모든 IPv4 주소가 소진되어 할당이 중지되었다. 이에 대한 대안으로 128비트 주소체계를 가진 IPv6가 등장했다.
-
- IPv4의 패킷 헤더는 고정 20바이트, 가변 40바이트로 구성된다. 헤더를 뒤따라 최대 65515바이트의 데이터가 있다.
- 참고 : https://ko.wikipedia.org/wiki/IPv4
- IPv6는 인터넷 기반 통신 프로토콜의 현재 버전이다.
- IPv6는 IPv4의 주소 고갈과 네트워크 프래그멘테이션 문제를 해결하고 인터넷에 확장성과 데이터 보안을 강화하기 위해 등장했다.
- IPv6와 기존 IPv4의 가장 큰 차이점은 바로 IP 주소의 길이가 128비트로 늘어났다는 점이다. 또한 여러가지 새로운 기능을 제공하는 동시에 기존 IPv4와의 호환성을 최대로 하는 방향으로 설게되었다.
- IP주소의 확장 : 기존 IPv4의 32비트 주소공간 이상으로, IPv6는 128비트 주소공간을 제공한다.
- 호스트 주소 자동 설정 : IPv6 호스트는 IPv6 네트워크에 접속하는 순간 자동적으로 네트워크 주소를 부여받는다.
- 패킷 크기 확장 : IPv4에서 패킷 크기는 64KB로 제한되어 있었다. IPv6의 점보 페이로드 옵션을 사용하면 특정 호스트 사이에는 임의로 큰 크기의 패킷을 주고받을 수 있도록 제한이 없어지게 된다.
- 효율적인 라우팅 : IP 패킷의 처리를 신속하게 할 수 있도록 고정크기의 단순한 헤더를 사용하는 동시에, 확장 헤더를 통해 네트워크 기능에 대한 확장 및 옵션기능의 확장이 용이한 구조로 정의하였다.
- 플로 레이블링(Flow Labeling) : 플로 레이블 개념을 도입, 특정 트래픽은 별도의 특별한 처리를 통해 높은 품질의 서비스를 제공할 수 있다.
- 인증 및 보안 기능 : 패킷 출처 인증과 데이터 무결성 및 비밀 보장 기능을 IP 프로토콜 체계에 반영하였다.
- 이동성 : IPv6 호스트는 네트워크의 물리적 위치에 제한받지 않고 같은 주소를 유지하면서도 자유롭게 이동할 수 있다.
- IPv6의 128비트 주소공간은 다음과 같이 16비트를 16진수로 표현하여 8자리로 나타낸다.
- 2001:0db8:85a3:08d3:1319:8a2e:0370:7334
- 그러나 대부분의 자리가 0의 숫자를 갖게 되므로, 0000을 하나의 0으로 축약하거나, 혹은 아예 연속으로 나타나는 0을 없애고 ':' 만을 남길 수 있다. 따라서 아래의 IPv6 주소들은 모두 같은 주소를 나타낸다.
- 2001:0DB8:0000:0000:0000:0000:1428:57ab
- 2001:0DB8:0000:0000:0000::1428:57ab
- 2001:0DB8:0:0:0:0:1428:57ab
- 2001:0DB8:0::0:1428:57ab
- 2001:0DB8::1428:57ab
- 2001:DB8::1428:57ab (각 자리 맨 앞의 0도 축약할 수 있다)
- 그러나 0을 축약하고 ':'로 없애는 규칙은 두 번 이상 적용할 수 없다. 만약 두 번 이상 적용하는 것이 허용되어 2001::25de::cade 와 같은 표현이 가능해진다면, 이 표현은 다음의 네 가지 주소 가운데 어떤 것을 가리키는지 의미가 불분명해질 것이다.
- 2001:0000:0000:0000:0000:25de:0000:cade
- 2001:0000:0000:0000:25de:0000:0000:cade
- 2001:0000:0000:25de:0000:0000:0000:cade
- 2001:0000:25de:0000:0000:0000:0000:cade
-
- IPv6의 패킷 헤더는 40바이트의 크기를 갖는다.
- 참고: https://ko.wikipedia.org/wiki/IPv6
4. HTTP
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. 클라이언트-서버 프로토콜이란 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온 하위 문서들로 재구성된다.
클라이언트와 서버들은 대이터 스트림과 대조적으로 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부른다.
HTTP는 어플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송된다. HTTP의 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML폼 결과와 같은 내용을 서버로 포스트하기 위해서도 사용한다. HTTP는 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.
HTTP 메시지
HTTP/1.1과 초기 HTTP 메시지는 사람이 읽을 수 있다. HTTP/2에서 이 메시지들은 새로운 이진 구조인 프레임 안으로 임베드 되어 헤더의 압축과 다중화와 같은 최적화를 가능케 한다.
HTTP 메시지의 두 가지 타입인 요청(requests)과 응답(responses)은 각자의 특성있는 형식을 가지고 있다.
요청은 다음의 요소들로 구성된다.
- Method : HTTP 메서드 : 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST같은 동사나 OPTIONS 나 HEAD와 같은 명사다.
- Path : 가져오려는 리소스의 경로 : URL에서 컨텍스트상 명백한 부분을 제외한 것입니다.
- Protocol version : HTTP 프로토콜의 버전
- Headers : 서버에 대한 추가 정보를 전달하는 선택적 헤더들
- Payload : POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문
응답은 다음의 요소들로 구성된다
- Protocol version : HTTP 프로토콜의 버전
- Status code : 요청의 성공 여부와 그 이유를 나타내는 상태 코드
- Status message : 아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지
- Headers : 요청 헤더와 비슷한 HTTP 헤더들
- Payload : 선택 사항으로 가져온 리소스가 포함되는 본문
참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
5. 웹 서버
웹 서버는 하드웨어, 소프트웨어 혹은 두 개가 같이 동작하는 것을 의미할 수 있다.
- 하드웨어 측면에서, 웹 서버는 웹 서버의 소프트웨어와 웹 사이트의 컴포넌트 파일들을 저장하는 컴퓨터다. 웹 서버는 인터넷에 연결되어 웹에 연결된 다른 기기들이 웹 서버의 데이터를 주고받을 수 있도록 한다.
- 소프트웨어 측면에서, 웹 서버는 기본적으로 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리한다. HTTP 서버는 URL과 HTTP의 소프트웨어 일부다.
브라우저가 웹 서버에서 파일을 필요로 할때, 브라우저는 HTTP를 통해 파일을 요청한다. 요청이 올바른 웹 서버에 도달하였을 때, HTTP서버는 요청된 문서를 HTTP를 이용해 보내준다.
웹 사이트를 공개하기 위해서는, 정적 혹은 동적 웹 서버가 필요하다.
- 정적 웹 서버 혹은 스택은 HTTP서버가 있는 컴퓨터로 구성되어있다. 서버가 파일을 있는 그대로 브라우저에 보내주기 때문에 정적이라고 부른다.
- 동적 웹 서버는 정적 웹 서버와 추가적인 소프트웨어로 구성되어 있다. 서버가 파일을 보내주기 전에 파일을 업데이트하기 떄문에 동적이라고 부른다.
참고: https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/What_is_a_web_server
6. 웹 어플리케이션 서버
웹 어플리케이션 서버(Web Application Server, WAS)는 웹 어플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. 웹 어플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행된다.
웹 어플리케이션 서버의 기본 기능은 3가지이다.
- 프로그램 실행 환경과 데이터베이스 접속 기능을 제공한다.
- 여러 개의 트랜잭션을 관리한다.
- 업무를 처리하는 비즈니스 로직을 수행한다.
- 다만 웹 어플리케이션의 정확한 정의는 존재하지 않아서 일부 기능을 제공하지 않는 웹 어플리케이션 서버도 존재한다.
6. JavaScript
JavaScript(JS)는 가벼운, 인터프리터 혹은 just-in-time 컴파일 프로그래밍 언어로, 일급 함수를 지원한다. 웹 페이지를 위한 스크립트 언어로 잘 알려져 있지만, Node.js, Apache CouchDB, Adobe Acrobat처럼 많은 비 브라우저 환경에서도 사용하고 있다. JavaScript는 프로토타입 기반, 다중 패러다임, 단일 스레드, 동적 언어로, 객체 지향형, 명령형, 선언형 스타일을 지원한다.
참고: https://developer.mozilla.org/ko/docs/Web/JavaScript