TIL 2021-11-16 ARP, cross-env, Tailwind CSS with Webpack

ARP

 

 

 

Switching과 Routing의 차이

 

Swithcing은 datalink layer에서 어느 인터페이스로 나가야하는지를 정해줌

 

Routing은 IP Layer에서 어떤 routing path를 통해 destination에 도착할 것인지를 정함

Header의 Type이 0x8060인 경우에 ARP임.

 

• Hardware Type: 어느 네트워크를 사용하는지(Ethernet 0x0001)
• Protocol Type : 어떠한 유형의 프로토콜 사용하는가? ARP은 IPv4에서 사용하므로 0x0800
• Hardware address length -> MAC -> 48bit -> 6byte
• Protocol address length -> 32bit -> 4byte
• Operation code : Request = 1, Reply = 2,
• Source hardware address : 내 MAC
• Source protocol address : 내 IP
• Target hardware address: 0.0.0.0 (모르기 때문)
• Source protocol address: 상대 IP

 

ARP는 Ethernet address resolution protocol이다.

Network Protocol Address를 48bit Ethernet 주소로 변환

 

Manual Mapping

 

X.25, ISDN에서 사용함(브로드캐스트를 지원하지 않기 떄문) -> ARP 사용하기 위해서는 브로드캐스트 지원되는 네트워크어야함

 

사람이 일일히 IP 주소와 하드웨어 주소를 할당해줌

 

단점

1.오래걸림

2.에러 발생 가능성 있음

3. 수동 업데이트 필요

 

 

동적 매핑

앱이나 유저, 관리자에 대한 걱정 없음

 

브로드캐스트 수용 능력을 위해 데이터링크 필요

 

ARP Operation

 

1.1.1.10/24를 가진 SVR1이 1.1.1.20/24를 가진 SVR2에 패킷을 보내고 싶을때, NetID를 통해서 같은 네트워크에 있다는 것을 알 수 있다.

 

SVR1은 SVR2의 맥 주소를 알기 위해 ARP 테이블을 참고했는데 비어있음

SVR2은 SVR2의 맥 주소를 알기 위해 lan1 port에 ARP Request를 보냄

S1(Switch 1)은 ARP 패킷을 받고 들어오는 패킷의 맥주소를 기록함(스위치는 IP Packet인지 ARP Packet인지 구분하지 않음)따라서 S1의 MAC 테이블은 [m1의 맥주소는 port fe1에 연결되어있음]을 기록함

 

Switch Self-learning mechanisms

스위치가 처음 켜졌을때 MAC 주소 테이블은 비어있음

source MAC address를 관찰하는 동적 학습을 통해 테이블을 만듦

 

1. 스위치는 HostA,HostB의 맥 주소 모름

2. HostA가 HostB에게로 프레임을 보낼때, HostA의 맥 주소를 테이블에 기록하고, 포트 ethernet1과 조합함

3. 스위치는 HostB가 A에게 다시 패킷을 보내기 전까지는 B의 맥 주소를 모름.

4. HostB의 MAC 주소는 포트 ethernet2와 조합됨

6. S1이 들어오는 패킷의 Dest MAC 주소를 찾아봄.(Broadcast 주소임)

패킷을 받는 포트를 제외하고 전부 flood함. 따라서 이 ARP Request패킷은ㅇ SVR2와 Router R1에 의해 받게 됨

7. R1는 받은 ARP Request 패킷의 주소를 찾아보고 이 주소가 자기 것이 아님을 확인하고 패킷을 버린다.

Router가 forward하지 않는 이유는 Broadcast주소는 forward하지 않기 떄문

8. SVR2가 ARP Reply에 응답함 (Unicast지 broadcast 패킷이 아니다)

9. ARP Reply를 받은 S1은 source MAC을 기록함

10. S1은 받은 패킷의 목표 MAC 주소 m1을 찾아보고, ARP Reply 패킷을 fe1 포트로 forward함

11. SVR1은 ARP Reply 패킷에 담긴 값을 ARP 테이블에 기록함

12. SVR1은 SVR2로 IP 패킷을 넘길 준비가 되엇고, port lan1의 설정에 따라서 IP 패킷을 forward한다.ㅋ

* 스위치는 프레임에 담긴 source MAC address만을 기반으로 MAC 주소 테이블을 만듦

 

Routing with ARP

 

SVR1이 SVR3에게 보내고 싶을때

 

1. SVR1은 ARP Request를 보낸다

 

2. R1은 ARP reply를 응답한다

 

3. SVR1은 R1에게 IP 패킷을 보낸다.

 

4. R1은 ARP Request를 보냄

R1은 라우팅 테이블을 참조해 direct attched된 목적지를 알아챈다.

 

5. Switch 2는 R1에서 보낸 ARP Request를 통해 R1의 src MAC을 기록함

 

6. SVR3이 ARP Reply 응답함

 

7. R1은 받은 ARP Reply 패킷을 ARP 테이블에 더함

 

8. R1은 SVR3에 IP 패킷을 전송함

 

 

Gratuitous ARP

 

자기 자신의 IP 주소로 ARP Request를 보냄

 

남 MAC 주소를 알기 위함이 아님

 

1. IP 충돌 탐지

이에 대한 응답이 있다면 이미 다른 호스트가 사용하는거임

2. ARP Table 업데이트하기 위함

 

 

Tailwindcss 웹팩에 적용

 

Postcss와 Autoprefix란?

 

Postcss은 자바스크립트 플러그인을 통해서 CSS를 transfile해주는 툴이다.

 

자체의 기능이 무언가가 있다기 보다는 PostCss를 지원하는 플러그인의 기반이 되는 라이브러리다.

 

Autoprefixer은 Can I Use를 기반으로 자동으로 vendor-prefix를 제공해주는 PostCss 플러그인이다.

 

Vendor prefix은 모든 브라우저에 지원되기 전에 새로 나온 CSS 기능들을 브라우저가 지원해주는 방법이다.

 

-webkit-(Chrome, Sapari...)

-moz-(Firefox)

-ms-(MicroSoft) 등의 단어가 붙은 css property를 본적이 있을텐데, 각각의 브라우저가 지원하는 기능에 붙는 접두어인 것이다.

 

파일 구조는

 

-public

--index.html

--main.js

-src

--index.js

--style.css

postcss.config.js

tailwind.config.js

webpack.config.js

 

이런 식으로 생겼다.

 

a {
    display: flex;
}

a {
    display: -webkit-box;
    display: -webkit-flex;
    display: -ms-flexbox;
    display: flex;
}

Autoprefixer은 이것은 자동으로 해주는 기능이다.

 

postcss-preset-env

 

a {
  color: rgb(0 0 100% / 90%);

  &:hover {
    color: rebeccapurple;
  }
}
------------------------------------

a {
  color: rgba(0, 0, 255, 0.9)
}

a:hover {
    color: rebeccapurple;
  }

@custom-selector :--heading h1, h2, h3, h4, h5, h6;
:--heading {
  margin-block: 0;
}
----------------------------------------------------


h1,h2,h3,h4,h5,h6 {
  margin-top: 0;
  margin-bottom: 0;
}

등 모던 CSS를 브라우저가 이해할 수 있는 형식으로 변환해주는 플러그인이다.

 

 

 

본격적으로 TailwindCss를 Webpack에 적용하기 위해서는 라이브러리를 설치해주어야한다.

 

yarn add postcss postcss-loader style-loader css-loader autoprefixer

 

style-loader는 DOM에 CSS를 주입해주는 기능

 

css-loader는 @import, url 등을 import/require() 형식으로 변환시켜주는 기능

 

postcss-loader는 postcss를 통해 css를 처리하는 기능을 하는 로더다.

 

postcss.config.js

module.exports = {
	plugins: [
		require('autoprefixer'),
		require('tailwindcss')('./tailwind.config.js'),
	],
};

tailwindcss와 autoprefixer 플러그인을 적용한다는 의미다.

 

tailwind.config.js

module.exports = {
	purge: ['./public/*.html'],
	darkMode: false,
	theme: {
		extend: {},
	},
	variants: {
		extend: {},
	},
	plugins: [],
};

purge는 사용하지 않는 클래스들을 모두 지워 최적화를 해주는 기능이다. 현재는./public/*.html로 public의 모든 html에서 사용하지 않는 클래스들을 지워주도록 하였다.

 

webpack.config.js

const path = require('path');

module.exports = {
	entry: './src/index.js',
	output: {
		filename: 'main.js',
		path: path.resolve(__dirname, 'public'),
	},
	mode: process.env.NODE_ENV === 'production' ? 'production' : 'development',
    
    
    ---------------------------------------------------------------------------------
	module: {
		rules: [
			{
				test: /\.css$/i,
				include: path.resolve(__dirname, 'src'),
				use: ['style-loader', 'css-loader', 'postcss-loader'],
			},
		],
	},
    ---------------------------------------------------------------------------------
};

중요한 것은 점선으로 표시해놓은 부분이다.

 

src의 모든 css를 체크하여 style-loader, css-loader, post-loader를 적용하도록 하였다.

 

참고로 main.js에 style.css를 'import ./style.css' 형식으로 넣어주었다.

 

 

 

빌드 도중 문제점

 

 

빌드를 했더니 총 번들 4.43MB라는 충격적인 결과가 나왔다!

 

분명 Purge를 하였는데, style.css의 용량이 4.06메가나 되는 것이었다.

 

이는 Production과 Development를 구분하지 않았기 때문에 Purge가 제대로 되지 않았기 때문이었고,

 

 

cross-env 라이브러리를 통해서 production으로 빌드해주었더니

 

36.5KB라는 납득할 수 있는 번들이 되었다.

 

 

 

알아볼 것

 

orphan module이 무엇인지

 

더 줄일 방법은 없는지?

 

 

번들 줄이는 것도 꽤나 재밌는거 같다.

 

 

부족한 것

 

main.js에서 css를 불러오는것이다보니 초반의 css 미적용 상태가 유의미하게 지속되는데, 이를 줄일 방법을 찾아봐야됨

 

Webpack에서 css파일 별도로 빌드 후 이를 html에서 불러오기?