프로토콜과 확장자 ✓
<JEPG로 확장자와 프로토콜에 대해서 설명>
JPEG 사진은 비슷한 색상을 묶어서 압축하는 방식을 사용한다. 이를 위해 사진은 여러 세그먼트로 나누어지고, 각 세그먼트는 압축된 형태로 저장된다. 이러한 세그먼트들은 OS에서 앱으로 전달될 때 12개씩 합쳐져서 전송된다. (대충 1byte씩 쪼개진게 12개로 합쳐져서 날아온다고 생각하면 편할듯?) 이는 프로토콜 수준에서 처리되며, 앱은 이를 받아서 조립하여 처리해야 한다. 받은 데이터는 12바이트씩 쪼개져서 도착하고, 이를 의미 있는 데이터로 조립해야 한다. 확장자는 주로 파일의 형식을 나타내는데 사용되지만, 통신 과정에서는 큰 의미를 갖지 않는다 (통신에서는 주로 데이터의 내용과 형식을 나타내는 MIME 타입이 사용되므로) (MIME 타입은 데이터의 종류와 형식을 정의하며, 파일의 확장자와는 독립적으로 사용) 그러나 파일을 쪼개어 보낸 후 다시 조립해야하므로, 확장자가 필요합니다
즉, 확장자란, '프로토콜(약속)'을 통해서 '내가 보낸 이미지의 '확장자'는 JPEG이니까 12바이트로 쪼개서 읽어!' '이건 확장자가 비트맵이거든? 비트맵 확장자는 읽을때 8바이트씩 쪼개서 읽는거 알지?' 하고 알려주는 것! .gif .jpg = 이런 확장자들은 이미지에 대한 전세계 표준 프로토콜이다. 웹에 대한 전세계적으로 표준화된 프로토콜은 HTTP(Hypertext Transfer Protocol)
프로토콜은 통신을 위한 규약으로, 상호 간에 데이터를 주고받는 방식과 형식을 정의
(= 데이터를 원활하고 신뢰성 있게 주고 받기 위해 필요한 약속을 규정하는 것!)
몇 개로 쪼개 먹는지 판단하는 건 앱이 하는 것. 프로토콜의 정의는 앱이 하는것!!!!
왜 12개씩 합쳐지는지?
JPEG 파일 형식의 특성과 압축 알고리즘에 기인한다.
일반적으로 JPEG은 12개의 블록이 하나의 그룹으로 묶이는데, 이는 전송 효율과 압축 효율을 균형있게 조정하기 위한 결정.
다른 예로, 비트맵은 8개씩 합쳐짐
HTTP (Hypertext Transfer Protocol)
웹에 대한 전세계적으로 표준화된 프로토콜 HTTP는 클라이언트가 웹 서버에게 요청(Request)을 보내고, 서버는 해당 요청에 대한 응답(Response)을 반환하는 방식으로 동작한다. 이를 통해 클라이언트는 웹 서버로부터 HTML, 이미지, 동영상 등의 다양한 리소스를 받아와 웹 페이지를 구성하고 표시할 수 있다.
HTTP는 웹 서버와 브라우저 간의 프로토콜
HTML (HyperText Markup Language)
웹 페이지의 구조와 내용을 기술하기 위해 사용되는 마크업 언어다. 웹 페이지를 만들기 위해 사용되며, 웹 브라우저에서 이해할 수 있는 형식으로 작성된다.
팀 버너스리가 논문 툴을 만들었다. 그게 바로 ‘브라우저’ (크롬 같은 것) - read만 함 즉, 브라우저는 뷰어 프로그램! 논문 작성은 평소에 사용하는 툴로 작성하면 됨. (자바로 따지면 이클립스, 인텔리J) (*처음에 HTML은 논문을 보는 목적)
논문에 필요한 것
- 언어
- 툴 (Write, Read)
확장자를 [ .html ] 으로 저장한다. 그 .html 의 뷰어가 바로 브라우저!
하이퍼 텍스트가 있는 마크업 랭기지 = HTML
markup language
마크업은 특정한 요소를 강조하거나 표시하기 위해 텍스트에 '태그'를 사용하는 것 보통 툴에서 마크업을 작업한다. [ 마크업 예시 ] <h1>안녕</h1> → h1은 헤딩1. 글자를 제목 1로 표시하라. <u>안녕</u> → 밑줄을 그어라 <Strong>안녕</Strong> → 글자 크기 굵게
대표적인 markup language는 html 이다
하이퍼 텍스트(Hypertext)
하이퍼텍스트는 텍스트 내에서 다른 문서나 웹 페이지로 이동할 수 있는 링크 링크는 특정 텍스트나 이미지를 클릭하면 연결된 페이지로 이동하거나 다른 리소스에 접근할 수 있도록 해주는 기능을 제공
HTML에서 <a> 태그는 하이퍼링크를 생성하는 데 사용
ex) <a>롤챔스</a> 같은 식으로 사용한다.
→ 이게 바로 HyperText Markup Language (HTML)의 핵심이다!
Web 서버
1. Web 서버의 정의
많은 [ .html 파일 ] 을 가지고 있는 앱은 웹 서버로 볼 수 있다. (서버인데... web이 많은?)
그래서 이 서버들을 web서버라고 함
2. Web 서버는 반이중
클라이언트가 웹서버에 필요한 논문 파일을 (.html) 요청하고, 웹서버가 응답 했잖아? 그럼 필요한 건 얻었잖아? 통신 유지할 필요 없이 끊는다. 그래서 웹은 반이중 통신!
3. Web 서버 스레드풀
웹 서버는 클라이언트의 요청이 들어올 때마다 요청을 처리하기 위한 스레드를 생성 (ip, port로 접속을 하니까... 소켓이 생성되고 그거? 소켓 수는 클라이언트 +1 그거?) 즉, 클라이언트 한 명당 스레드 한 개가 생성되는 셈. 많은 클라이언트 요청이 동시에 발생할 경우, CPU 낭비!!! 그래서 이걸 해결하기 위해 스레드 풀을 만들어 놓는다. 모든 서버는 스레드 풀이 있다!
내 CPU가 감당할 수 있을 만큼의 스레드풀을 만들어 놓는다. 스레드 풀이 100개라면 동시에 최대 100개의 클라이언트 요청을 처리할 수 있는 셈. (=동시 접속이 100개까지 가능) 그 이상의 클라이언트 요청이 들어오면 대기 상태(웨이팅)에 들어가게 된다. (ex. 티켓팅........)
스레드 풀을 사용하면 스레드를 생성하고 삭제하는 오버헤드도 줄일 수 있다. (= 메인 시작할때 스레드 100개를 미리 만들어놓기 때문에 삭제할 필요도 없다.) (-> 스레드 풀이 미리 생성된 스레드를 재사용함으로써 가능) 스레드 풀은 필요한 만큼의 스레드를 미리 생성하여 힙 영역에 할당하고, 필요할 때마다 해당 스레드를 재사용하여 오버헤드를 줄일 수 있다. 힙은 프로그램이 실행되는 동안 필요한 메모리를 동적으로 할당하고 해제하는 공간. 스레드 풀은 여러 개의 스레드를 관리하기 위한 도구로, 스레드를 미리 만들어놓고 필요할 때 사용하는 방식이라, heap에 할당되어 관리! ...static이 아니었네!
오버헤드란?
물건을 만들거나 작업을 할 때, 추가적인 비용이나 시간, 자원이 발생하는 것.
이 비용이나 시간, 자원은 실제 작업을 하는 데에 직접적으로 필요하지 않지만
필요한 작업을 위해 사용되는 것들이다
클라이언트 한 명당 스레드 한 개!!!! 꼭 알기!!! 외우고 있기!!!!!
스레드풀과 풀링 기술은 다른 것…이라네
4. URL
인터넷 상의 파일이나 데이터베이스 같은 자원(파일)에 대한 주소를 지정하는 방법 (인터넷에 있는 자원의 위치를 나타내기 위한 규약)
웹 서버에 요청을 보내기 위해서는 IP 주소와 포트 번호를 알아야 한다. 때문에, BW에서 URL에 프로토콜, IP 주소, 포트 번호, 자원명을 포함하여 요청한다. ex) [ http://IP주소:80//k.html ] 같은 형식 * 호스트 이름, 파일 이름은 꼭 필요. 나머지는 생략 가능
DNS 때문에 naver.com 을 IP주소로 인식한다.
naver.com은 호스트 이름이라고도 불린다.
클라이언트가 툴(브라우저)를 사용해서 url을 넣고, HDD에 파일을 요청한다. 그러면 이 URL이 BufferedWriter를 타고 건너가서 BufferedReader를 사용하여 클라이언트의 요청을 읽는다. 웹서버는 해당 요청에 대한 적절한 응답을 생성하여 클라이언트에게 보낸다. 그리고 찾아온 .html을 브라우저에 표시
웹 서버의 기본 포트 번호는 80번. 서버 소켓의 포트가 80번인 것.
서버소켓을 때리면 애가 새로운 소켓을 만들어서 응답하는 것임
[ http://IP주소:80 ] = 브라우저가 소켓을 만들어낼 때 필요한 것
[ //k.html ] = app에서 받는 소켓의 입장에서는 자원명(k.html)이 중요함
해당 정보를 이용해서 찾기 때문!
내가 URL을 줄테니까, 니가 자원명을 파싱해서, HDD에서 찾아서 나한테 줘
> 최초의 프로토콜을 GET 프로토콜 이라고 함.
> 웹서버가 클라이언트로부터 파일을 보여달라고 요청하는 것
Share article